Method and apparatus for transmitting/receiving a broadcast signal

ABSTRACT

A method for transmitting a broadcast signal is disclosed. The method for transmitting a broadcast signal according to an embodiment of the present invention includes link layer processing IP/UDP data to output a link layer packet, and physical layer processing the link layer packet based on a PLP.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a Continuation of U.S. patent application Ser. No.15/742,397, filed on Jan. 5, 2018, now allowed, which is the NationalStage filing under 35 U.S.C. 371 of International Application No.PCT/KR2016/007441, filed on Jul. 8, 2016, which claims the benefit ofU.S. Provisional Application No. 62/189,754, filed on Jul. 8, 2015, U.S.Provisional Application No. 62/204,407, filed on Aug. 12, 2015 and U.S.Provisional Application No. 62/209,900, filed on Aug. 26, 2015, thecontents of which are all hereby incorporated by reference herein intheir entirety.

TECHNICAL FIELD

The present invention relates to an apparatus for transmitting abroadcast signal, an apparatus for receiving a broadcast signal, amethod for transmitting a broadcast signal and a method for receiving abroadcast signal.

BACKGROUND ART

As analog broadcast signal transmission comes to an end, varioustechnologies for transmitting/receiving digital broadcast signals havebeen developed. A digital broadcast signal may include a larger amountof video/audio data than an analog broadcast signal and may furtherinclude various types of additional data in addition to the video/audiodata.

DISCLOSURE Technical Problem

A digital broadcast system may provide HD (high definition) images,multi-channel audio and various additional services. However, datatransmission efficiency for transmission of large amounts of data,robustness of transmission/reception networks and network flexibility inconsideration of mobile reception equipment need to be improved fordigital broadcast.

Technical Solution

The present invention proposes a method for transmitting a broadcastsignal and an apparatus for transmitting a broadcast signal.

A method for transmitting a broadcast signal according to an embodimentof the present invention may include link layer processing IP/UDP datato output a link layer packet, and physical layer processing the linklayer packet based on a PLP, where the link layer processing may includeencapsulating the IP/UDP data and link layer signaling information intoa separate link layer packet, where the link layer packet may include atleast one of a base header, an additional header, an optional header ora payload, and the optional header includes Sub-stream ID (SID)information identifying a specific IP/UDP sub-stream included in thelink layer packet, and where the specific IP/UDP sub-stream may indicatea specific data set identified in IP/UDP network layer, and the IP/UDPsub-stream may be identified by source IP address information,destination IP address information, source UDP port information anddestination UDP port information.

In addition, in an embodiment of the present invention, the link layersignaling information may include mapping information for the PLP andIP/UDP data carried in the PLP, the mapping information may include PLPnumber information, IP/UDP sub-stream number information included in aPLP, source IP address information for each IP/UDP sub-stream,destination IP address information, source UDP port information anddestination UDP port information, and SID information for the IP/UDPsub-stream, and the SID information may be used for filtering the IP/UDPsub-stream included in the PLP in a link layer level.

In addition, in an embodiment of the present invention, the additionalheader of the link layer packet may include flag information indicatingwhether the SID information is included in the optional header.

In addition, in an embodiment of the present invention, the link layerprocessing may further include compressing an IP header of the IP/UDPpacket and generating at least one of an IR packet, an IR-DYN packet ora compressed packet and an adaptation step for selectively convertingthe compressed IP/UDP packet.

In addition, in an embodiment of the present invention, the operationalmode of the adaptation step may include: a first adaptation mode inwhich the IR packet, the IR-DYN packet and the compressed packet arebypassed, a second adaptation mode in which context information of theIR packet is extracted and the IR packet is converted into the IR-DYNpacket; and a third adaptation mode in which context information of theIR packet and the IR-DYN packet is extracted and the IR packet and theIR-DYN packet are converted into the compressed packet.

In addition, in an embodiment of the present invention, the link layersignaling information may include description information for the IPheader compression, and the description information may include theextracted context information.

In addition, in an embodiment of the present invention, the link layersignaling packet may be included in a PLP forwarding a service listtable, and the service list table may be signaling informationdescribing a service.

A broadcast signal transmitter according to an embodiment of the presentinvention that performs the method for transmitting a broadcast signalmay include a link layer processor configured to link layer processIP/UDP data to output a link layer packet; and a physical layerprocessor configured to physical layer process the link layer packetbased on a PLP, where the link layer processor is configured toencapsulate the IP/UDP data and link layer signaling information into aseparate link layer packet, where the link layer packet may include atleast one of a base header, an additional header, an optional header ora payload, and the optional header includes Sub-stream ID (SID)information identifying a specific IP/UDP sub-stream included in thelink layer packet, and where the specific IP/UDP sub-stream may indicatea specific data set identified in IP/UDP network layer, and the IP/UDPsub-stream may be identified by source IP address information,destination IP address information, source UDP port information anddestination UDP port information.

Technical Effects

The present invention may process data according to servicecharacteristics to control Quality of Services (QoS) for each service orservice component, thereby providing various broadcast services.

The present invention may achieve transmission flexibility bytransmitting various broadcast services through the same radio frequency(RF) signal bandwidth.

The present invention may provide a method and apparatus fortransmitting/receiving a broadcast signal capable of receiving digitalbroadcast signals without an error even in the case of using a mobilereception device or in an indoor environment.

The present invention may support a next generation broadcast serviceefficiently in the environment that supports the hybrid broadcast thatuses a terrestrial broadcast network and an internet network.

Hereinafter, the additional effects of the present invention may bedescribed together with the construction of the invention.

DESCRIPTION OF DRAWINGS

FIG. 1 is a diagram showing a protocol stack according to an embodimentof the present invention.

FIG. 2 is a diagram showing a service discovery procedure according toone embodiment of the present invention.

FIG. 3 is a diagram showing a low level signaling (LLS) table and aservice list table (SLT) according to one embodiment of the presentinvention.

FIG. 4 is a diagram showing a USBD and an S-TSID delivered through ROUTEaccording to one embodiment of the present invention.

FIG. 5 is a diagram showing a USBD delivered through MMT according toone embodiment of the present invention.

FIG. 6 is a diagram showing link layer operation according to oneembodiment of the present invention.

FIG. 7 is a diagram showing a link mapping table (LMT) according to oneembodiment of the present invention.

FIG. 8 illustrates a configuration of a broadcast signal transmissionapparatus for future broadcast services according to an embodiment ofthe present invention.

FIG. 9 illustrates a write operation of a time interleaver according toan embodiment of the present invention.

FIG. 10 illustrates an interleaving address generator including a mainpseudo-random binary sequence (PRBS) generator and a sub-PRBS generatoraccording to each FFT mode which are included in a frequency interleaveraccording to an embodiment of the present invention.

FIG. 11 illustrates a link layer packet according to an embodiment ofthe present invention.

FIG. 12 illustrates a structure of a link layer packet in more detailaccording to an embodiment of the present invention.

FIG. 13 illustrates a procedure for transmitting and receiving broadcastdata using an SID according to an embodiment of the present invention.

FIG. 14 illustrates link layer signaling information according to anembodiment of the present invention.

FIG. 15 illustrates an IPv4 packet header structure according to anembodiment of the present invention.

FIG. 16 illustrates an IPv6 packet header structure according to anembodiment of the present invention.

FIG. 17 illustrates a UDP packet header structure according to anembodiment of the present invention.

FIG. 18 illustrates mapping information for an index and IP address/portnumber as link layer signaling information according to an embodiment ofthe present invention.

FIG. 19 illustrates mapping information according to an embodiment ofthe present invention.

FIG. 20 illustrates mapping information according to an embodiment ofthe present invention.

FIG. 21 illustrates service session information according to anembodiment of the present invention.

FIG. 22 illustrates mapping information according to an embodiment ofthe present invention.

FIG. 23 illustrates mapping information according to an embodiment ofthe present invention.

FIG. 24 illustrates a link layer processing of transmitter/receiveraccording to an embodiment of the present invention.

FIG. 25 illustrates mapping information according to an embodiment ofthe present invention.

FIG. 26 illustrates service session information according to anembodiment of the present invention.

FIG. 27 illustrates a link layer processing of transmitter/receiveraccording to an embodiment of the present invention.

FIG. 28 illustrates link layer mapping information according to anembodiment of the present invention.

FIG. 29 illustrates an operational structure of a transmitter accordingto an embodiment of the present invention.

FIG. 30 illustrates an operational structure of a receiver according toan embodiment of the present invention.

FIG. 31 illustrates an operational structure of a receiver according toanother embodiment of the present invention.

FIG. 32 illustrates mapping information according to an embodiment ofthe present invention.

FIG. 33 illustrates an operational structure of a transmitter accordingto an embodiment of the present invention.

FIG. 34 illustrates an operational structure of a receiver according toan embodiment of the present invention.

FIG. 35 illustrates an operational structure of a receiver according toanother embodiment of the present invention.

FIG. 36 illustrates an IP header compression of a first adaptation modeaccording to an embodiment of the present invention.

FIG. 37 illustrates a transmission operation of a first adaptation modeaccording to an embodiment of the present invention.

FIG. 38 illustrates a reception operation of a first adaptation modeaccording to an embodiment of the present invention.

FIG. 39 illustrates an IP header compression of a second adaptation modeaccording to an embodiment of the present invention.

FIG. 40 illustrates a transmission operation of a second adaptation modeaccording to an embodiment of the present invention.

FIG. 41 illustrates a reception operation of a second adaptation modeaccording to an embodiment of the present invention.

FIG. 42 illustrates an IP header compression of a third adaptation modeaccording to an embodiment of the present invention.

FIG. 43 illustrates a transmission operation of a third adaptation modeaccording to an embodiment of the present invention.

FIG. 44 illustrates a reception operation of a second adaptation modeaccording to an embodiment of the present invention.

FIG. 45 illustrates RoHC-U Description Table (RDT) information accordingto an embodiment of the present invention.

FIG. 46 illustrates a broadcast signal transmitter and a broadcastsignal receiver according to an embodiment of the present invention.

FIG. 47 illustrates a broadcast signal transmission method according toan embodiment of the present invention.

BEST MODE FOR INVENTION

Reference will now be made in detail to the preferred embodiments of thepresent invention, examples of which are illustrated in the accompanyingdrawings. The detailed description, which will be given below withreference to the accompanying drawings, is intended to explain exemplaryembodiments of the present invention, rather than to show the onlyembodiments that can be implemented according to the present invention.The following detailed description includes specific details in order toprovide a thorough understanding of the present invention. However, itwill be apparent to those skilled in the art that the present inventionmay be practiced without such specific details.

Although most terms used in the present invention have been selectedfrom general ones widely used in the art, some terms have beenarbitrarily selected by the applicant and their meanings are explainedin detail in the following description as needed. Thus, the presentinvention should be understood based upon the intended meanings of theterms rather than their simple names or meanings. Also, the term blockand module are used similarly to indicate logical/functional unit ofparticular signal/data processing.

The present invention provides apparatuses and methods for transmittingand receiving broadcast signals for future broadcast services. Futurebroadcast services according to an embodiment of the present inventioninclude a terrestrial broadcast service, a mobile broadcast service, aUHDTV service, etc. The present invention may process broadcast signalsfor the future broadcast services through non-MIMO or MIMO according toone embodiment. A non-MIMO scheme according to an embodiment of thepresent invention may include a multiple input single output (MISO)scheme, a single input single output (SISO) scheme, etc. The presentinvention proposes a physical profile (or system) optimized to minimizereceiver complexity while attaining the performance required for aparticular use case.

FIG. 1 is a diagram showing a protocol stack according to an embodimentof the present invention.

A service may be delivered to a receiver through a plurality of layers.First, a transmission side may generate service data. The service datamay be processed for transmission at a delivery layer of thetransmission side and the service data may be encoded into a broadcastsignal and transmitted over a broadcast or broadband network at aphysical layer.

Here, the service data may be generated in an ISO base media file format(BMFF). ISO BMFF media files may be used for broadcast/broadband networkdelivery, media encapsulation and/or synchronization format. Here, theservice data is all data related to the service and may include servicecomponents configuring a linear service, signaling information thereof,non real time (NRT) data and other files.

The delivery layer will be described. The delivery layer may provide afunction for transmitting service data. The service data may bedelivered over a broadcast and/or broadband network.

Broadcast service delivery may include two methods.

As a first method, service data may be processed in media processingunits (MPUs) based on MPEG media transport (MMT) and transmitted usingan MMT protocol (MMTP). In this case, the service data delivered usingthe MMTP may include service components for a linear service and/orservice signaling information thereof.

As a second method, service data may be processed into DASH segments andtransmitted using real time object delivery over unidirectionaltransport (ROUTE), based on MPEG DASH. In this case, the service datadelivered through the ROUTE protocol may include service components fora linear service, service signaling information thereof and/or NRT data.That is, the NRT data and non-timed data such as files may be deliveredthrough ROUTE.

Data processed according to MMTP or ROUTE protocol may be processed intoIP packets through a UDP/IP layer. In service data delivery over thebroadcast network, a service list table (SLT) may also be delivered overthe broadcast network through a UDP/IP layer. The SLT may be deliveredin a low level signaling (LLS) table. The SLT and LLS table will bedescribed later.

IP packets may be processed into link layer packets in a link layer. Thelink layer may encapsulate various formats of data delivered from ahigher layer into link layer packets and then deliver the packets to aphysical layer. The link layer will be described later.

In hybrid service delivery, at least one service element may bedelivered through a broadband path. In hybrid service delivery, datadelivered over broadband may include service components of a DASHformat, service signaling information thereof and/or NRT data. This datamay be processed through HTTP/TCP/IP and delivered to a physical layerfor broadband transmission through a link layer for broadbandtransmission.

The physical layer may process the data received from the delivery layer(higher layer and/or link layer) and transmit the data over thebroadcast or broadband network. A detailed description of the physicallayer will be given later.

The service will be described. The service may be a collection ofservice components displayed to a user, the components may be of variousmedia types, the service may be continuous or intermittent, the servicemay be real time or non real time, and a real-time service may include asequence of TV programs.

The service may have various types. First, the service may be a linearaudio/video or audio service having app based enhancement. Second, theservice may be an app based service, reproduction/configuration of whichis controlled by a downloaded application. Third, the service may be anESG service for providing an electronic service guide (ESG). Fourth, theservice may be an emergency alert (EA) service for providing emergencyalert information.

When a linear service without app based enhancement is delivered overthe broadcast network, the service component may be delivered by (1) oneor more ROUTE sessions or (2) one or more MMTP sessions.

When a linear service having app based enhancement is delivered over thebroadcast network, the service component may be delivered by (1) one ormore ROUTE sessions or (2) zero or more MMTP sessions. In this case,data used for app based enhancement may be delivered through a ROUTEsession in the form of NRT data or other files. In one embodiment of thepresent invention, simultaneous delivery of linear service components(streaming media components) of one service using two protocols may notbe allowed.

When an app based service is delivered over the broadcast network, theservice component may be delivered by one or more ROUTE sessions. Inthis case, the service data used for the app based service may bedelivered through the ROUTE session in the form of NRT data or otherfiles.

Some service components of such a service, some NRT data, files, etc.may be delivered through broadband (hybrid service delivery).

That is, in one embodiment of the present invention, linear servicecomponents of one service may be delivered through the MMT protocol. Inanother embodiment of the present invention, the linear servicecomponents of one service may be delivered through the ROUTE protocol.In another embodiment of the present invention, the linear servicecomponents of one service and NRT data (NRT service components) may bedelivered through the ROUTE protocol. In another embodiment of thepresent invention, the linear service components of one service may bedelivered through the MMT protocol and the NRT data (NRT servicecomponents) may be delivered through the ROUTE protocol. In theabove-described embodiments, some service components of the service orsome NRT data may be delivered through broadband. Here, the app basedservice and data regarding app based enhancement may be delivered overthe broadcast network according to ROUTE or through broadband in theform of NRT data. NRT data may be referred to as locally cached data.

Each ROUTE session includes one or more LCT sessions for wholly orpartially delivering content components configuring the service. Instreaming service delivery, the LCT session may deliver individualcomponents of a user service, such as audio, video or closed captionstream. The streaming media is formatted into a DASH segment.

Each MMTP session includes one or more MMTP packet flows for deliveringall or some of content components or an MMT signaling message. The MMTPpacket flow may deliver a component formatted into MPU or an MMTsignaling message.

For delivery of an NRT user service or system metadata, the LCT sessiondelivers a file based content item. Such content files may includeconsecutive (timed) or discrete (non-timed) media components of the NRTservice or metadata such as service signaling or ESG fragments. Systemmetadata such as service signaling or ESG fragments may be deliveredthrough the signaling message mode of the MMTP.

A receiver may detect a broadcast signal while a tuner tunes tofrequencies. The receiver may extract and send an SLT to a processingmodule. The SLT parser may parse the SLT and acquire and store data in achannel map. The receiver may acquire and deliver bootstrap informationof the SLT to a ROUTE or MMT client. The receiver may acquire and storean SLS. USBD may be acquired and parsed by a signaling parser.

FIG. 2 is a diagram showing a service discovery procedure according toone embodiment of the present invention.

A broadcast stream delivered by a broadcast signal frame of a physicallayer may carry low level signaling (LLS). LLS data may be carriedthrough payload of IP packets delivered to a well-known IP address/port.This LLS may include an SLT according to type thereof. The LLS data maybe formatted in the form of an LLS table. A first byte of every UDP/IPpacket carrying the LLS data may be the start of the LLS table. Unlikethe shown embodiment, an IP stream for delivering the LLS data may bedelivered to a PLP along with other service data.

The SLT may enable the receiver to generate a service list through fastchannel scan and provides access information for locating the SLS. TheSLT includes bootstrap information. This bootstrap information mayenable the receiver to acquire service layer signaling (SLS) of eachservice. When the SLS, that is, service signaling information, isdelivered through ROUTE, the bootstrap information may include an LCTchannel carrying the SLS, a destination IP address of a ROUTE sessionincluding the LCT channel and destination port information. When the SLSis delivered through the MMT, the bootstrap information may include adestination IP address of an MMTP session carrying the SLS anddestination port information.

In the shown embodiment, the SLS of service #1 described in the SLT isdelivered through ROUTE and the SLT may include bootstrap informationsIP1, dIP1 and dPort1 of the ROUTE session including the LCT channeldelivered by the SLS. The SLS of service #2 described in the SLT isdelivered through MMT and the SLT may include bootstrap informationsIP2, dIP2 and dPort2 of the MMTP session including the MMTP packet flowdelivered by the SLS.

The SLS is signaling information describing the properties of theservice and may include receiver capability information forsignificantly reproducing the service or providing information foracquiring the service and the service component of the service. Wheneach service has separate service signaling, the receiver acquiresappropriate SLS for a desired service without parsing all SLSs deliveredwithin a broadcast stream.

When the SLS is delivered through the ROUTE protocol, the SLS may bedelivered through a dedicated LCT channel of a ROUTE session indicatedby the SLT. In some embodiments, this LCT channel may be an LCT channelidentified by tsi=0. In this case, the SLS may include a user servicebundle description (USBD)/user service description (USD), service-basedtransport session instance description (S-TSID) and/or mediapresentation description (MPD).

Here, USBD/USD is one of SLS fragments and may serve as a signaling hubdescribing detailed description information of a service. The USBD mayinclude service identification information, device capabilityinformation, etc. The USBD may include reference information (URIreference) of other SLS fragments (S-TSID, MPD, etc.). That is, theUSBD/USD may reference the S-TSID and the MPD. In addition, the USBD mayfurther include metadata information for enabling the receiver to decidea transmission mode (broadcast/broadband network). A detaileddescription of the USBD/USD will be given below.

The S-TSID is one of SLS fragments and may provide overall sessiondescription information of a transport session carrying the servicecomponent of the service. The S-TSID may provide the ROUTE sessionthrough which the service component of the service is delivered and/ortransport session description information for the LCT channel of theROUTE session. The S-TSID may provide component acquisition informationof service components associated with one service. The S-TSID mayprovide mapping between DASH representation of the MPD and the tsi ofthe service component. The component acquisition information of theS-TSID may be provided in the form of the identifier of the associatedDASH representation and tsi and may or may not include a PLP ID in someembodiments. Through the component acquisition information, the receivermay collect audio/video components of one service and perform bufferingand decoding of DASH media segments. The S-TSID may be referenced by theUSBD as described above. A detailed description of the S-TSID will begiven below.

The MPD is one of SLS fragments and may provide a description of DASHmedia presentation of the service. The MPD may provide a resourceidentifier of media segments and provide context information within themedia presentation of the identified resources. The MPD may describeDASH representation (service component) delivered over the broadcastnetwork and describe additional DASH presentation delivered overbroadband (hybrid delivery). The MPD may be referenced by the USBD asdescribed above.

When the SLS is delivered through the MMT protocol, the SLS may bedelivered through a dedicated MMTP packet flow of the MMTP sessionindicated by the SLT. In some embodiments, the packet_id of the MMTPpackets delivering the SLS may have a value of 00. In this case, the SLSmay include a USBD/USD and/or MMT packet (MP) table.

Here, the USBD is one of SLS fragments and may describe detaileddescription information of a service as in ROUTE. This USBD may includereference information (URI information) of other SLS fragments. The USBDof the MMT may reference an MP table of MMT signaling. In someembodiments, the USBD of the MMT may include reference information ofthe S-TSID and/or the MPD. Here, the S-TSID is for NRT data deliveredthrough the ROUTE protocol. Even when a linear service component isdelivered through the MMT protocol, NRT data may be delivered via theROUTE protocol. The MPD is for a service component delivered overbroadband in hybrid service delivery. The detailed description of theUSBD of the MMT will be given below.

The MP table is a signaling message of the MMT for MPU components andmay provide overall session description information of an MMTP sessioncarrying the service component of the service. In addition, the MP tablemay include a description of an asset delivered through the MMTPsession. The MP table is streaming signaling information for MPUcomponents and may provide a list of assets corresponding to one serviceand location information (component acquisition information) of thesecomponents. The detailed description of the MP table may be defined inthe MMT or modified. Here, the asset is a multimedia data entity, iscombined by one unique ID, and may mean a data entity used to onemultimedia presentation. The asset may correspond to service componentsconfiguring one service. A streaming service component (MPU)corresponding to a desired service may be accessed using the MP table.The MP table may be referenced by the USBD as described above.

The other MMT signaling messages may be defined. Additional informationassociated with the service and the MMTP session may be described bysuch MMT signaling messages.

The ROUTE session is identified by a source IP address, a destination IPaddress and a destination port number. The LCT session is identified bya unique transport session identifier (TSI) within the range of a parentROUTE session. The MMTP session is identified by a destination IPaddress and a destination port number. The MMTP packet flow isidentified by a unique packet_id within the range of a parent MMTPsession.

In case of ROUTE, the S-TSID, the USBD/USD, the MPD or the LCT sessiondelivering the same may be referred to as a service signaling channel.In case of MMTP, the USBD/UD, the MMT signaling message or the packetflow delivering the same may be referred to as a service signalingchannel.

Unlike the shown embodiment, one ROUTE or MMTP session may be deliveredover a plurality of PLPs. That is, one service may be delivered throughone or more PLPs. Unlike the shown embodiment, in some embodiments,components configuring one service may be delivered through differentROUTE sessions. In addition, in some embodiments, components configuringone service may be delivered through different MMTP sessions. In someembodiments, components configuring one service may be divided anddelivered in a ROUTE session and an MMTP session. Although not shown,components configuring one service may be delivered through broadband(hybrid delivery).

FIG. 3 is a diagram showing a low level signaling (LLS) table and aservice list table (SLT) according to one embodiment of the presentinvention.

One embodiment t3010 of the LLS table may include information accordingto an LLS_table_id field, a provider_id field, an LLS_table_versionfield and/or an LLS_table_id field.

The LLS_table_id field may identify the type of the LLS table, and theprovider_id field may identify a service provider associated withservices signaled by the LLS table. Here, the service provider is abroadcaster using all or some of the broadcast streams and theprovider_id field may identify one of a plurality of broadcasters whichis using the broadcast streams. The LLS_table_version field may providethe version information of the LLS table.

According to the value of the LLS_table_id field, the LLS table mayinclude one of the above-described SLT, a rating region table (RRT)including information on a content advisory rating, SystemTimeinformation for providing information associated with a system time, acommon alert protocol (CAP) message for providing information associatedwith emergency alert. In some embodiments, the other information may beincluded in the LLS table.

One embodiment t3020 of the shown SLT may include an @bsid attribute, an@sltCapabilities attribute, an sltInetUrl element and/or a Serviceelement. Each field may be omitted according to the value of the shownUse column or a plurality of fields may be present.

The @bsid attribute may be the identifier of a broadcast stream. The@sltCapabilities attribute may provide capability information requiredto decode and significantly reproduce all services described in the SLT.The sltInetUrl element may provide base URL information used to obtainservice signaling information and ESG for the services of the SLT overbroadband. The sltInetUrl element may further include an @urlTypeattribute, which may indicate the type of data capable of being obtainedthrough the URL.

The Service element may include information on services described in theSLT, and the Service element of each service may be present. The Serviceelement may include an @serviceId attribute, an @sltSvcSeqNum attribute,an @protected attribute, an @majorChannelNo attribute, an@minorChannelNo attribute, an @serviceCategory attribute, an@shortServiceName attribute, an @hidden attribute, an@broadbandAccessRequired attribute, an @svcCapabilities attribute, aBroadcastSvcSignaling element and/or an svcInetUrl element.

The @serviceId attribute is the identifier of the service and the@sltSvcSeqNum attribute may indicate the sequence number of the SLTinformation of the service. The @protected attribute may indicatewhether at least one service component necessary for significantreproduction of the service is protected. The @majorChannelNo attributeand the @minorChannelNo attribute may indicate the major channel numberand minor channel number of the service, respectively.

The @serviceCategory attribute may indicate the category of the service.The category of the service may include a linear A/V service, a linearaudio service, an app based service, an ESG service, an EAS service,etc. The @shortServiceName attribute may provide the short name of theservice. The @hidden attribute may indicate whether the service is fortesting or proprietary use. The @broadbandAccessRequired attribute mayindicate whether broadband access is necessary for significantreproduction of the service. The @svcCapabilities attribute may providecapability information necessary for decoding and significantreproduction of the service.

The BroadcastSvcSignaling element may provide information associatedwith broadcast signaling of the service. This element may provideinformation such as location, protocol and address with respect tosignaling over the broadcast network of the service. Details thereofwill be described below.

The svcInetUrl element may provide URL information for accessing thesignaling information of the service over broadband. The sltInetUrlelement may further include an @urlType attribute, which may indicatethe type of data capable of being obtained through the URL.

The above-described BroadcastSvcSignaling element may include an@slsProtocol attribute, an @slsMajorProtocolVersion attribute, an@slsMinorProtocolVersion attribute, an @slsPlpId attribute, an@slsDestinationIpAddress attribute, an @slsDestinationUdpPort attributeand/or an @slsSourceIpAddress attribute.

The @slsProtocol attribute may indicate the protocol used to deliver theSLS of the service (ROUTE, MMT, etc.). The @slsMajorProtocolVersionattribute and the @slsMinorProtocolVersion attribute may indicate themajor version number and minor version number of the protocol used todeliver the SLS of the service, respectively.

The @slsPlpId attribute may provide a PLP identifier for identifying thePLP delivering the SLS of the service. In some embodiments, this fieldmay be omitted and the PLP information delivered by the SLS may bechecked using a combination of the information of the below-describedLMT and the bootstrap information of the SLT.

The @slsDestinationIpAddress attribute, the @slsDestinationUdpPortattribute and the @slsSourceIpAddress attribute may indicate thedestination IP address, destination UDP port and source IP address ofthe transport packets delivering the SLS of the service, respectively.These may identify the transport session (ROUTE session or MMTP session)delivered by the SLS. These may be included in the bootstrapinformation.

FIG. 4 is a diagram showing a USBD and an S-TSID delivered through ROUTEaccording to one embodiment of the present invention.

One embodiment t4010 of the shown USBD may have a bundleDescription rootelement. The bundleDescription root element may have auserServiceDescription element. The userServiceDescription element maybe an instance of one service.

The userServiceDescription element may include an @globalServiceIDattribute, an @serviceId attribute, an @serviceStatus attribute, an@fullMPDUri attribute, an @sTSIDUri attribute, a name element, aserviceLanguage element, a capabilityCode element and/or adeliveryMethod element. Each field may be omitted according to the valueof the shown Use column or a plurality of fields may be present.

The @globalServiceID attribute is the globally unique identifier of theservice and may be used for link with ESG data(Service@globalServiceID). The @serviceId attribute is a referencecorresponding to the service entry of the SLT and may be equal to theservice ID information of the SLT. The @serviceStatus attribute mayindicate the status of the service. This field may indicate whether theservice is active or inactive.

The @fullMPDUri attribute may reference the MPD fragment of the service.The MPD may provide a reproduction description of a service componentdelivered over the broadcast or broadband network as described above.The @sTSIDUri attribute may reference the S-TSID fragment of theservice. The S-TSID may provide parameters associated with access to thetransport session carrying the service as described above.

The name element may provide the name of the service. This element mayfurther include an slang attribute and this field may indicate thelanguage of the name provided by the name element. The serviceLanguageelement may indicate available languages of the service. That is, thiselement may arrange the languages capable of being provided by theservice.

The capabilityCode element may indicate capability or capability groupinformation of a receiver necessary to significantly reproduce theservice. This information is compatible with capability informationformat provided in service announcement.

The deliveryMethod element may provide transmission related informationwith respect to content accessed over the broadcast or broadband networkof the service. The deliveryMethod element may include abroadcastAppService element and/or a unicastAppService element. Each ofthese elements may have a basePattern element as a sub element.

The broadcastAppService element may include transmission associatedinformation of the DASH representation delivered over the broadcastnetwork. The DASH representation may include media components over allperiods of the service presentation.

The basePattern element of this element may indicate a character patternused for the receiver to perform matching with the segment URL. This maybe used for a DASH client to request the segments of the representation.Matching may imply delivery of the media segment over the broadcastnetwork.

The unicastAppService element may include transmission relatedinformation of the DASH representation delivered over broadband. TheDASH representation may include media components over all periods of theservice media presentation.

The basePattern element of this element may indicate a character patternused for the receiver to perform matching with the segment URL. This maybe used for a DASH client to request the segments of the representation.Matching may imply delivery of the media segment over broadband.

One embodiment t4020 of the shown S-TSID may have an S-TSID rootelement. The S-TSID root element may include an @serviceId attributeand/or an RS element. Each field may be omitted according to the valueof the shown Use column or a plurality of fields may be present.

The @serviceId attribute is the identifier of the service and mayreference the service of the USBD/USD. The RS element may describeinformation on ROUTE sessions through which the service components ofthe service are delivered. According to the number of ROUTE sessions, aplurality of elements may be present. The RS element may further includean @bsid attribute, an @slpAddr attribute, an @dlpAddr attribute, an@dport attribute, an @PLPID attribute and/or an LS element.

The @bsid attribute may be the identifier of a broadcast stream in whichthe service components of the service are delivered. If this field isomitted, a default broadcast stream may be a broadcast stream includingthe PLP delivering the SLS of the service. The value of this field maybe equal to that of the @bsid attribute.

The @slpAddr attribute, the @dlpAddr attribute and the @dport attributemay indicate the source IP address, destination IP address anddestination UDP port of the ROUTE session, respectively. When thesefields are omitted, the default values may be the source address,destination IP address and destination UDP port values of the currentROUTE session delivering the SLS, that is, the S-TSID. This field maynot be omitted in another ROUTE session delivering the servicecomponents of the service, not in the current ROUTE session.

The @PLPID attribute may indicate the PLP ID information of the ROUTEsession. If this field is omitted, the default value may be the PLP IDvalue of the current PLP delivered by the S-TSID. In some embodiments,this field is omitted and the PLP ID information of the ROUTE sessionmay be checked using a combination of the information of thebelow-described LMT and the IP address/UDP port information of the RSelement.

The LS element may describe information on LCT channels through whichthe service components of the service are transmitted. According to thenumber of LCT channel, a plurality of elements may be present. The LSelement may include an @tsi attribute, an @PLPID attribute, an @bwattribute, an @startTime attribute, an @endTime attribute, a SrcFlowelement and/or a RepairFlow element.

The @tsi attribute may indicate the tsi information of the LCT channel.Using this, the LCT channels through which the service components of theservice are delivered may be identified. The @PLPID attribute mayindicate the PLP ID information of the LCT channel. In some embodiments,this field may be omitted. The @bw attribute may indicate the maximumbandwidth of the LCT channel. The @startTime attribute may indicate thestart time of the LCT session and the @endTime attribute may indicatethe end time of the LCT channel.

The SrcFlow element may describe the source flow of ROUTE. The sourceprotocol of ROUTE is used to transmit a delivery object and at least onesource flow may be established within one ROUTE session. The source flowmay deliver associated objects as an object flow.

The RepairFlow element may describe the repair flow of ROUTE. Deliveryobjects delivered according to the source protocol may be protectedaccording to forward error correction (FEC) and the repair protocol maydefine an FEC framework enabling FEC protection.

FIG. 5 is a diagram showing a USBD delivered through MMT according toone embodiment of the present invention.

One embodiment of the shown USBD may have a bundleDescription rootelement. The bundleDescription root element may have auserServiceDescription element. The userServiceDescription element maybe an instance of one service.

The userServiceDescription element may include an @globalServiceIDattribute, an @serviceId attribute, a Name element, a serviceLanguageelement, a contentAdvisoryRating element, a Channel element, ampuComponent element, a routeComponent element, a broadbandComponentelement and/or a ComponentInfo element. Each field may be omittedaccording to the value of the shown Use column or a plurality of fieldsmay be present.

The @globalServiceID attribute, the @serviceId attribute, the Nameelement and/or the serviceLanguage element may be equal to the fields ofthe USBD delivered through ROUTE. The contentAdvisoryRating element mayindicate the content advisory rating of the service. This information iscompatible with content advisory rating information format provided inservice announcement. The Channel element may include informationassociated with the service. A detailed description of this element willbe given below.

The mpuComponent element may provide a description of service componentsdelivered as the MPU of the service. This element may further include an@mmtPackageId attribute and/or an @nextMmtPackageId attribute. The@mmtPackageId attribute may reference the MMT package of the servicecomponents delivered as the MPU of the service. The @nextMmtPackageIdattribute may reference an MMT package to be used after the MMT packagereferenced by the @mmtPackageId attribute in terms of time. Through theinformation of this element, the MP table may be referenced.

The routeComponent element may include a description of the servicecomponents of the service. Even when linear service components aredelivered through the MMT protocol, NRT data may be delivered accordingto the ROUTE protocol as described above. This element may describeinformation on such NRT data. A detailed description of this elementwill be given below.

The broadbandComponent element may include the description of theservice components of the service delivered over broadband. In hybridservice delivery, some service components of one service or other filesmay be delivered over broadband. This element may describe informationon such data. This element may further an @fullMPDUri attribute. Thisattribute may reference the MPD describing the service componentdelivered over broadband. In addition to hybrid service delivery, thebroadcast signal may be weakened due to traveling in a tunnel and thusthis element may be necessary to support handoff between broadband andbroadband. When the broadcast signal is weak, the service component isacquired over broadband and, when the broadcast signal becomes strong,the service component is acquired over the broadcast network to secureservice continuity.

The ComponentInfo element may include information on the servicecomponents of the service. According to the number of service componentsof the service, a plurality of elements may be present. This element maydescribe the type, role, name, identifier or protection of each servicecomponent. Detailed information of this element will be described below.

The above-described Channel element may further include an @serviceGenreattribute, an @serviceIcon attribute and/or a ServiceDescriptionelement. The @serviceGenre attribute may indicate the genre of theservice and the @serviceIcon attribute may include the URL informationof the representative icon of the service. The ServiceDescriptionelement may provide the service description of the service and thiselement may further include an @serviceDescrText attribute and/or an@serviceDescrLang attribute. These attributes may indicate the text ofthe service description and the language used in the text.

The above-described routeComponent element may further include an@sTSIDUri attribute, an @sTSIDDestinationIpAddress attribute, an@sTSIDDestinationUdpPort attribute, an @sTSIDSourceIpAddress attribute,an @sTSIDMajorProtocolVersion attribute and/or an@sTSIDMinorProtocolVersion attribute.

The @sTSIDUri attribute may reference an S-TSID fragment. This field maybe equal to the field of the USBD delivered through ROUTE. This S-TSIDmay provide access related information of the service componentsdelivered through ROUTE. This S-TSID may be present for NRT datadelivered according to the ROUTE protocol in a state of deliveringlinear service component according to the MMT protocol.

The @sTSIDDestinationIpAddress attribute, the @sTSIDDestinationUdpPortattribute and the @sTSIDSourceIpAddress attribute may indicate thedestination IP address, destination UDP port and source IP address ofthe transport packets carrying the above-described S-TSID. That is,these fields may identify the transport session (MMTP session or theROUTE session) carrying the above-described S-TSID.

The @sTSIDMajorProtocolVersion attribute and the@sTSIDMinorProtocolVersion attribute may indicate the major versionnumber and minor version number of the transport protocol used todeliver the above-described S-TSID, respectively.

The above-described ComponentInfo element may further include an@componentType attribute, an @componentRole attribute, an@componentProtectedFlag attribute, an @componentId attribute and/or an@componentName attribute.

The @componentType attribute may indicate the type of the component. Forexample, this attribute may indicate whether the component is an audio,video or closed caption component. The @componentRole attribute mayindicate the role of the component. For example, this attribute mayindicate main audio, music, commentary, etc. if the component is anaudio component. This attribute may indicate primary video if thecomponent is a video component. This attribute may indicate a normalcaption or an easy reader type if the component is a closed captioncomponent.

The @componentProtectedFlag attribute may indicate whether the servicecomponent is protected, for example, encrypted. The @componentIdattribute may indicate the identifier of the service component. Thevalue of this attribute may be the asset_id (asset ID) of the MP tablecorresponding to this service component. The @componentName attributemay indicate the name of the service component.

FIG. 6 is a diagram showing link layer operation according to oneembodiment of the present invention.

The link layer may be a layer between a physical layer and a networklayer. A transmission side may transmit data from the network layer tothe physical layer and a reception side may transmit data from thephysical layer to the network layer (t6010). The purpose of the linklayer is to compress (abstract) all input packet types into one formatfor processing by the physical layer and to secure flexibility andexpandability of an input packet type which is not defined yet. Inaddition, the link layer may provide option for compressing(abstracting) unnecessary information of the header of input packets toefficiently transmit input data. Operation such as overhead reduction,encapsulation, etc. of the link layer is referred to as a link layerprotocol and packets generated using this protocol may be referred to aslink layer packets. The link layer may perform functions such as packetencapsulation, overhead reduction and/or signaling transmission.

At the transmission side, the link layer (ALP) may perform an overheadreduction procedure with respect to input packets and then encapsulatethe input packets into link layer packets. In addition, in someembodiments, the link layer may perform encapsulation into the linklayer packets without performing the overhead reduction procedure. Dueto use of the link layer protocol, data transmission overhead on thephysical layer may be significantly reduced and the link layer protocolaccording to the present invention may provide IP overhead reductionand/or MPEG-2 TS overhead reduction.

When the shown IP packets are input as input packets (t6010), the linklayer may sequentially perform IP header compression, adaptation and/orencapsulation. In some embodiments, some processes may be omitted. Forexample, the RoHC module may perform IP packet header compression toreduce unnecessary overhead. Context information may be extractedthrough the adaptation procedure and transmitted out of band. The IPheader compression and adaption procedure may be collectively referredto as IP header compression. Thereafter, the IP packets may beencapsulated into link layer packets through the encapsulationprocedure.

When MPEG 2 TS packets are input as input packets, the link layer maysequentially perform overhead reduction and/or an encapsulationprocedure with respect to the TS packets. In some embodiments, someprocedures may be omitted. In overhead reduction, the link layer mayprovide sync byte removal, null packet deletion and/or common headerremoval (compression). Through sync byte removal, overhead reduction of1 byte may be provided per TS packet. Null packet deletion may beperformed in a manner in which reinsertion is possible at the receptionside. In addition, deletion (compression) may be performed in a mannerin which common information between consecutive headers may be restoredat the reception side. Some of the overhead reduction procedures may beomitted. Thereafter, through the encapsulation procedure, the TS packetsmay be encapsulated into link layer packets. The link layer packetstructure for encapsulation of the TS packets may be different from thatof the other types of packets.

First, IP header compression will be described.

The IP packets may have a fixed header format but some informationnecessary for a communication environment may be unnecessary for abroadcast environment. The link layer protocol may compress the headerof the IP packet to provide a mechanism for reducing broadcast overhead.

IP header compression may employ a header compressor/decompressor and/oran adaptation module. The IP header compressor (RoHC compressor) mayreduce the size of each IP packet header based on the RoHC scheme.Thereafter, the adaptation module may extract context information andgenerate signaling information from each packet stream. A receiver mayparse signaling information associated with the packet stream and attachcontext information to the packet stream. The RoHC decompressor mayrestore the packet header to reconfigure an original IP packet.Hereinafter, IP header compression may mean only IP header compressionby a header compression or a combination of IP header compression and anadaptation process by an adaptation module. The same is true indecompressing.

Hereinafter, adaptation will be described.

In transmission of a single-direction link, when the receiver does nothave context information, the decompressor cannot restore the receivedpacket header until complete context is received. This may lead tochannel change delay and turn-on delay. Accordingly, through theadaptation function, configuration parameters and context informationbetween the compressor and the decompressor may be transmitted out ofband. The adaptation function may provide construction of link layersignaling using context information and/or configuration parameters. Theadaptation function may use previous configuration parameters and/orcontext information to periodically transmit link layer signalingthrough each physical frame.

Context information is extracted from the compressed IP packets andvarious methods may be used according to adaptation mode.

Mode #1 refers to a mode in which no operation is performed with respectto the compressed packet stream and an adaptation module operates as abuffer.

Mode #2 refers to a mode in which an IR packet is detected from acompressed packet stream to extract context information (static chain).After extraction, the IR packet is converted into an IR-DYN packet andthe IR-DYN packet may be transmitted in the same order within the packetstream in place of an original IR packet.

Mode #3 (t6020) refers to a mode in which IR and IR-DYN packets aredetected from a compressed packet stream to extract context information.A static chain and a dynamic chain may be extracted from the IR packetand a dynamic chain may be extracted from the IR-DYN packet. Afterextraction, the IR and IR-DYN packets are converted into normalcompression packets. The converted packets may be transmitted in thesame order within the packet stream in place of original IR and IR-DYNpackets.

In each mode, the context information is extracted and the remainingpackets may be encapsulated and transmitted according to the link layerpacket structure for the compressed IP packets. The context informationmay be encapsulated and transmitted according to the link layer packetstructure for signaling information, as link layer signaling.

The extracted context information may be included in a RoHC-Udescription table (RDT) and may be transmitted separately from the RoHCpacket flow. Context information may be transmitted through a specificphysical data path along with other signaling information. The specificphysical data path may mean one of normal PLPs, a PLP in which low levelsignaling (LLS) is delivered, a dedicated PLP or an L1 signaling path.Here, the RDT may be context information (static chain and/or dynamicchain) and/or signaling information including information associatedwith header compression. In some embodiments, the RDT shall betransmitted whenever the context information is changed. In addition, insome embodiments, the RDT shall be transmitted every physical frame. Inorder to transmit the RDT every physical frame, the previous RDT may bereused.

The receiver may select a first PLP and first acquire signalinginformation of the SLT, the RDT, the LMT, etc., prior to acquisition ofa packet stream. When signaling information is acquired, the receivermay combine the signaling information to acquire mapping betweenservice—IP information—context information—PLP. That is, the receivermay check which service is transmitted in which IP streams or which IPstreams are delivered in which PLP and acquire context information ofthe PLPs. The receiver may select and decode a PLP carrying a specificpacket stream. The adaptation module may parse context information andcombine the context information with the compressed packets. To thisend, the packet stream may be restored and delivered to the RoHCdecompressor. Thereafter, decompression may start. At this time, thereceiver may detect IR packets to start decompression from an initiallyreceived IR packet (mode 1), detect IR-DYN packets to startdecompression from an initially received IR-DYN packet (mode 2) or startdecompression from any compressed packet (mode 3).

Hereinafter, packet encapsulation will be described.

The link layer protocol may encapsulate all types of input packets suchas IP packets, TS packets, etc. into link layer packets. To this end,the physical layer processes only one packet format independently of theprotocol type of the network layer (here, an MPEG-2 TS packet isconsidered as a network layer packet). Each network layer packet orinput packet is modified into the payload of a generic link layerpacket.

In the packet encapsulation procedure, segmentation may be used. If thenetwork layer packet is too large to be processed in the physical layer,the network layer packet may be segmented into two or more segments. Thelink layer packet header may include fields for segmentation of thetransmission side and recombination of the reception side. Each segmentmay be encapsulated into the link layer packet in the same order as theoriginal location.

In the packet encapsulation procedure, concatenation may also be used.If the network layer packet is sufficiently small such that the payloadof the link layer packet includes several network layer packets,concatenation may be performed. The link layer packet header may includefields for performing concatenation. In concatenation, the input packetsmay be encapsulated into the payload of the link layer packet in thesame order as the original input order.

The link layer packet may include a header and a payload. The header mayinclude a base header, an additional header and/or an optional header.The additional header may be further added according to situation suchas concatenation or segmentation and the additional header may includefields suitable for situations. In addition, for delivery of theadditional information, the optional header may be further included.Each header structure may be predefined. As described above, if theinput packets are TS packets, a link layer header having packetsdifferent from the other packets may be used.

Hereinafter, link layer signaling will be described.

Link layer signaling may operate at a level lower than that of the IPlayer. The reception side may acquire link layer signaling faster thanIP level signaling of the LLS, the SLT, the SLS, etc. Accordingly, linklayer signaling may be acquired before session establishment.

Link layer signaling may include internal link layer signaling andexternal link layer signaling. Internal link layer signaling may besignaling information generated at the link layer. This includes theabove-described RDT or the below-described LMT. External link layersignaling may be signaling information received from an external module,an external protocol or a higher layer. The link layer may encapsulatelink layer signaling into a link layer packet and deliver the link layerpacket. A link layer packet structure (header structure) for link layersignaling may be defined and link layer signaling information may beencapsulated according to this structure.

FIG. 7 is a diagram showing a link mapping table (LMT) according to oneembodiment of the present invention.

The LMT may provide a list of higher layer sessions carried through thePLP. In addition, the LMT may provide additional information forprocessing link layer packets carrying the higher layer sessions. Here,the higher layer session may also be referred to as multicast.Information on IP streams or transport sessions transmitted through aspecific PLP may be acquired through the LMT. In contrast, informationon through which PLP a specific transport session is delivered may beacquired.

The LMT may be delivered in any PLP identified as carrying LLS. Here,the PLP in which the LLS is delivered may be identified by an LLS flagof L1 detail signaling information of a physical layer. The LLS flag maybe a flag field indicating whether the LLS is delivered in the PLP, eachPLP. Here, L1 detail signaling information may correspond to thebelow-described PLS2 data.

That is, the LMT may be delivered in the same PLP along with the LLS.Each LMT shall describe mapping between PLPs and IP addresses/ports asdescribed above. As described above, the LLS may include an SLT and theIP address/port described in the LMT may be any IP address/portassociated with any service described in the SLT delivered in the samePLP as the LMT.

In some embodiments, the PLP identifier information in theabove-described SLT, SLS, etc. may be used to confirm informationindicating through which PLP a specific transport session indicated bythe SLT or SLS is transmitted may be confirmed.

In another embodiment, the PLP identifier information in theabove-described SLT, SLS, etc. will be omitted and PLP information ofthe specific transport session indicated by the SLT or SLS may beconfirmed by referring to the information in the LMT. In this case, thereceiver may combine the LMT and other IP level signaling information toidentify the PLP. Even in this embodiment, the PLP information in theSLT, SLS, etc. is not omitted and may remain in the SLT, SLS, etc.

The LMT according to the shown embodiment may include a signaling_typefield, a PLP_ID field, a num_session field and/or information on eachsession. Although the LMT of the shown embodiment describes IP streamstransmitted through one PLP, a PLP loop may be added to the LMT todescribe information on a plurality of PLPs in some embodiments. In thiscase, the LMT may describe, in a PLP loop, PLPs for any IP address/portassociated with any service described in the SLT delivered together, asdescribed above.

The signaling_type field may indicate the type of signaling informationdelivered by the table. The value of signaling_type field for the LMTmay be set to 0x01. The signaling_type field may be omitted. The PLP_IDfield may identify a target PLP to be described. If the PLP loop isused, each PLP_ID field may identify each target PLP. The PLP_ID fieldand subsequent fields thereof may be included in the PLP loop. Thebelow-described PLP_ID field is an identifier for one PLP of the PLPloop and the below-described fields may be fields for the correspondingPLP.

The num_session field may indicate the number of higher layer sessionsdelivered through the PLP identified by the corresponding PLP_ID field.According to the number indicated by the num_session field, informationon each session may be included. This information may include asrc_IP_add field, a dst_IP_add field, a src_UDP_port field, adst_UDP_port field, an SID_flag field, a compressed_flag field, an SIDfield and/or a context_id field.

The src_IP_add field, the dst_IP_add field, the src_UDP_port field andthe dst_UDP_port field may indicate the source IP address, thedestination IP address, the source UDP port and the destination UDP portof the transport session among the higher layer sessions deliveredthrough the PLP identified by the corresponding PLP_ID field.

The SID_flag field may indicate whether the link layer packet deliveringthe transport session has an SID field in the optional header. The linklayer packet delivering the higher layer session may have an SID fieldin the optional header and the SID field value may be equal to that ofthe SID field in the LMT.

The compressed_flag field may indicate whether header compression isapplied to the data of the link layer packet delivering the transportsession. In addition, presence/absence of the below-described context_idfield may be determined according to the value of this field. If headercompression is applied (compressed_flag=1), the RDT may be present andthe PLP ID field of the RDT may have the same value as the PLP_ID fieldassociated with this compressed_flag field.

The SID field may indicate the SIDs (sub stream IDs) of the link layerpackets delivering the transport session. These link layer packets mayinclude SIDs having the same values as this SID field in the optionalheader thereof. To this end, the receiver may filter link layer packetsusing LMT information and the SID information of the link layer packetheader, without parsing all link layer packets.

The context_id field may provide a reference for a context id (CID) inthe RDT. The CID information of the RDT may indicate the context ID ofthe compression IP packet stream. The RDT may provide contextinformation of the compression IP packet stream. Through this field, theRDT and the LMT may be associated.

In the above-described embodiments of the signaling information/table ofthe present invention, the fields, elements or attributes may be omittedor may be replaced with other fields. In some embodiments, additionalfields, elements or attributes may be added.

In one embodiment of the present invention, service components of oneservice may be delivered through a plurality of ROUTE sessions. In thiscase, an SLS may be acquired through bootstrap information of an SLT. AnS-TSID and an MPD may be referenced through the USBD of the SLS. TheS-TSID may describe not only the ROUTE session delivered by the SLS butalso transport session description information of another ROUTE sessioncarried by the service components. To this end, the service componentsdelivered through the plurality of ROUTE sessions may all be collected.This is similarly applicable to the case in which the service componentsof one service are delivered through a plurality of MMTP sessions. Forreference, one service component may be simultaneously used by theplurality of services.

In another embodiment of the present invention, bootstrapping of an ESGservice may be performed by a broadcast or broadband network. Byacquiring the ESG over broadband, URL information of the SLT may beused. ESG information may be requested using this URL.

In another embodiment of the present invention, one service component ofone service may be delivered over the broadcast network and the otherservice component may be delivered over broadband (hybrid). The S-TSIDmay describe components delivered over the broadcast network such thatthe ROUTE client acquires desired service components. In addition, theUSBD may have base pattern information to describe which segments (whichcomponents) are delivered through which path. Accordingly, the receivercan confirm a segment to be requested from the broadband service and asegment to be detected in a broadcast stream.

In another embodiment of the present invention, scalable coding of aservice may be performed. The USBD may have all capability informationnecessary to render the service. For example, when one service isprovided in HD or UHD, the capability information of the USBD may have avalue of “HD or UHD”. The receiver may check which component isreproduced in order to render the UHD or HD service using the MPD.

In another embodiment of the present invention, through a TOI field ofthe LCT packets delivered through the LCT channel delivering the SLS,which SLS fragment is delivered using the LCT packets (USBD, S-TSID,MPD, etc.) may be identified.

In another embodiment of the present invention, app components to beused for app based enhancement/an app based service may be deliveredover the broadcast network as NRT components or may be delivered overbroadband. In addition, app signaling for app based enhancement may beperformed by an application signaling table (AST) delivered along withthe SLS. In addition, an event which is signaling for operation to beperformed by the app may be delivered in the form of an event messagetable (EMT) along with the SLS, may be signaled in the MPD or may bein-band signaled in the form of a box within DASH representation. TheAST, the EMT, etc. may be delivered over broadband. App basedenhancement, etc. may be provided using the collected app components andsuch signaling information.

In another embodiment of the present invention, a CAP message may beincluded and provided in the above-described LLS table for emergencyalert. Rich media content for emergency alert may also be provided. Richmedia may be signaled by a CAP message and, if rich media is present,the rich media may be provided as an EAS service signaled by the SLT.

In another embodiment of the present invention, linear servicecomponents may be delivered over the broadcast network according to theMMT protocol. In this case, NRT data (e.g., app components) of theservice may be delivered over the broadcast network according to theROUTE protocol. In addition, the data of the service may be deliveredover broadband. The receiver may access the MMTP session delivering theSLS using the bootstrap information of the SLT. The USBD of the SLSaccording to the MMT may reference the MP table such that the receiveracquires linear service components formatted into the MPU deliveredaccording to the MMT protocol. In addition, the USBD may furtherreference the S-TSID such that the receiver acquires NRT data deliveredaccording to the ROUTE protocol. In addition, the USBD may furtherreference the MPD to provide a reproduction description of datadelivered over broadband.

In another embodiment of the present invention, the receiver may deliverlocation URL information capable of acquiring a file content item (file,etc.) and/or a streaming component to a companion device through a websocket method. The application of the companion device may acquirecomponents, data, etc. through a request through HTTP GET using thisURL. In addition, the receiver may deliver information such as systemtime information, emergency alert information, etc. to the companiondevice.

FIG. 8 illustrates a configuration of a broadcast signal transmissionapparatus for future broadcast services according to an embodiment ofthe present invention.

The broadcast signal transmission apparatus for future broadcastservices according to the present embodiment may include an inputformatting block 1000, a bit interleaved coding & modulation (BICM)block 1010, a frame building block 1020, an OFDM generation block 1030and a signaling generation block 1040. Description will be given of anoperation of each block of the broadcast signal transmission apparatus.

In input data according to an embodiment of the present invention, IPstream/packets and MPEG2-TS may be main input formats, and other streamtypes are handled as general streams.

The input formatting block 1000 may demultiplex each input stream intoone or a plurality of data pipes, to each of which independent codingand modulation are applied. A DP is the basic unit for robustnesscontrol, which affects QoS. One or a plurality of services or servicecomponents may be carried by one DP. The DP is a logical channel in aphysical layer for delivering service data or related metadata capableof carrying one or a plurality of services or service components.

Since QoS depends on characteristics of a service provided by thebroadcast signal transmission apparatus for future broadcast servicesaccording to the embodiment of the present invention, data correspondingto respective services needs to be processed using different schemes.

BICM block 1010 may include a processing block for a profile (or system)to which MIMO is not applied, and a processing block for a profile (orsystem) to which MIMO is applied and may comprise a plurality blocks forprocessing each Data Pipe.

A processing block of the BICM block to which MIMO is not applied mayinclude a data FEC encoder, a bit interleaver, a constellation mapper, asignal space diversity (SSD) encoding block and a time interleaver. Aprocessing block of the BICM block to which MIMO is applied may isdistinguished from the processing block of the BICM block to which MIMOis not applied in that the processing block further includes a cell-worddemultiplexer and a MIMO encoding block

The data FEC encoder performs FEC encoding on an input BBF to generateFECBLOCK procedure using outer coding (BCH) and inner coding (LDPC). Theouter coding (BCH) is optional coding method. The bit interleaver mayinterleave outputs of the data FEC encoder to achieve optimizedperformance with a combination of LDPC codes and a modulation schemewhile providing an efficiently implementable structure. A detailedoperation of the bit interleaver will be described later. Theconstellation mapper may modulate each cell word from the bitinterleaver or the cell-word demultiplexer in the advanced profile usingeither QPSK, QAM-16, non-uniform QAM (NUQ-64, NUQ-256, or NUQ-1024) ornon-uniform constellation (NUC-16, NUC-64, NUC-256, or NUC-1024) mappingto give a power-normalized constellation point. This constellationmapping is applied only for DPs. It is observed that QAM-16 and NUQs aresquare shaped, while NUCs have arbitrary shapes. Both NUQs and NUCs aredefined specifically for each code rate and the particular one used issignaled by the parameter DP_MOD field in the PLS2 data. The timeinterleaver may operates at a DP level. Parameters of time interleaving(TI) may be set differently for each DP. The time interleaver accordingto an embodiment of the present invention can be positioned between aBICM chain block and a frame builder.

Here, the time interleaver according to an embodiment of the presentinvention can use both a convolutional interleaver (CI) and a blockinterleaver (BI) or selectively using either the CI or the BI accordingto a physical layer pipe (PLP) mode. A PLP according to an embodiment ofthe present invention is a physical path corresponding to the sameconcept as that of the above-described DP, and a name of the PLP may bechanged by a designer. A PLP mode according to an embodiment of thepresent invention may include a single PLP mode or a multi-PLP modeaccording to the number of PLPs processed by a broadcast signaltransmitter or a broadcast signal transmission apparatus. In the presentinvention, time interleaving in which different time interleavingschemes are applied according to PLP modes may be referred to as hybridtime interleaving.

The hybrid time interleaver may include a BI and a CI. That is, whenPLP_NUM=1, the BI is not applied (BI is turned OFF) and only the CI isapplied. When PLP_NUM>1, both the BI and the CI may be applied (BI isturned ON). A structure and an operation of the CI applied whenPLP_NUM>1 may be different from a case of PLP_NUM=1. The hybrid timedeinterleaver may perform an operation corresponding to an inverseoperation of the hybrid time interleaver described above.

The cell-word demultiplexer is used for dividing a single cell-wordstream into dual cell-word streams for MIMO processing. The MIMOencoding block may process an output of the cell-word demultiplexerusing a MIMO encoding scheme. The MIMO encoding scheme of the presentinvention may be defined as full-rate spatial multiplexing (FR-SM) toprovide capacity increase with relatively small complexity increase atthe receiver side. MIMO processing is applied at the DP level. NUQ (e1,iand e2,i) corresponding to a pair of constellation mapper outputs is fedto an input of a MIMO encoder and paired MIMO encoder output (g1,i andg2,i) is transmitted by the same carrier k and OFDM symbol I ofrespective TX antennas thereof.

The frame building block 1020 may map the data cells of the input DPsinto the OFDM symbols within a frame, and perform frequency interleavingfor frequency-domain diversity.

A frame according to an embodiment of the present invention is furtherdivided into a preamble, one or more frame signaling symbols (FSSs),normal data symbols. The preamble provides a set of basic transmissionparameters for efficient transmission and reception of a signal. And thepreamble indicates whether the emergency alert service (EAS) is providedin a current frame or not. A main purpose of the FSS is to carry PLSdata. For fast synchronization and channel estimation, and hence fastdecoding of PLS data, the FSS has a dense pilot pattern than a normaldata symbol.

The frame building block 1020 may include a delay compensation block foradjusting timing between DPs and corresponding PLS data to ensure thatthe DPs and the corresponding PLS data are co-timed at a transmitterside, a cell mapper for mapping PLS, DPs, auxiliary streams, dummycells, etc. to active carriers of the OFDM symbols in the frame and afrequency interleaver.

The frequency interleaver may randomly interleave data cells receivedfrom the cell mapper to provide frequency diversity. In addition, thefrequency interleaver may operate on data corresponding to an OFDMsymbol pair including two sequential OFDM symbols or an OFDM symbolusing a different interleaving-seed order to obtain maximum interleavinggain in a single frame.

The OFDM generation block 1030 modulates OFDM carriers by cells producedby the frame building block, inserts pilots, and produces a time domainsignal for transmission. In addition, this block subsequently insertsguard intervals, and applies peak-to-average power ratio (PAPR)reduction processing to produce a final RF signal.

The signaling generation block 1040 may create physical layer signalinginformation used for an operation of each functional block. Signalinginformation according to an embodiment of the present invention mayinclude PLS data. The PLS data includes PLS1 data and PLS2 data.

The PLS1 data is a first set of PLS data carried in an FSS symbol in aframe having a fixed size, coding and modulation, which carries basicinformation about the system in addition to the parameters needed todecode the PLS2 data. The PLS1 data provides basic transmissionparameters including parameters required to enable reception anddecoding of the PLS2 data. In addition, the PLS1 data remains constantfor the duration of a frame group. The PLS2 data is a second set of PLSdata transmitted in an FSS symbol, which carries more detailed PLS dataabout the system and the DPs. The PLS2 contains parameters that providesufficient information for the receiver to decode a desired DP. The PLS2signaling further includes two types of parameters, PLS2 static data(PLS2-STAT data) and PLS2 dynamic data (PLS2-DYN data). The PLS2 staticdata is PLS2 data that remains static for the duration of a frame groupand the PLS2 dynamic data is PLS2 data that dynamically changes frame byframe.

PLS2 data can include FIC_flag information. FIC (fast informationchannel) is a dedicated channel for carrying cross-layer information toenable fast service acquisition and channel scanning. FIC_FLAG is a1-bit field and indicates whether the FIC is used in a current frame. Ifthis field is set to ‘1’, the FIC is provided in the current frame. Ifthis field set to ‘0’, the FIC is not carried in the current frame. TheBICM block 1010 may include BICM block for protection of the PLS dataincluding a PLS FEC encoder, a bit interleaver and a constellationmapper.

The PLS FEC encoder may include a scrambler for scrambling PLS1 data andPLS2 data, a BCH encoding/zero insertion block for outer encoding on thescrambled PLS1,2 data using a shortened BCH code for PLS protection, andinsert zero bits after BCH encoding, an LDPC encoding block for LDPCencoding using an LDPC code and an LDPC parity puncturing block. The bitinterleaver may interleave each of shortened and punctured PLS1 data andPLS2 data. The constellation mapper may map the bit-interleaved PLS1data and PLS2 data to constellations.

The broadcast signal reception apparatus for future broadcast servicesaccording to the embodiment of the present invention may correspond tothe broadcast signal transmission apparatus for future broadcastservices described with reference to FIG. 8.

The broadcast signal reception apparatus for future broadcast servicesaccording to the embodiment of the present invention may include asynchronization & demodulation module carrying out demodulationcorresponding to a reverse procedure of a procedure performed by thebroadcast signal transmission apparatus, a frame parsing module parsinginput signal frames and extracting data through which a service selectedby a user is transmitted, a demapping & decoding module which convertinput signals into bit domain data and then deinterleave the same asnecessary, perform demapping of mapping applied for transmissionefficiency and correct an error generated on a transmission channelthrough decoding, an output processor performing reverse procedures ofvarious compression/signal processing procedures which are applied bythe broadcast signal transmission apparatus and a signaling decodingmodule obtaining PLS information from a signal demodulated by thesynchronization & demodulation module.

The frame parsing module, the demapping & decoding module and the outputprocessor may execute functions thereof using data output from thesignaling decoding module. According to an embodiment of the presentinvention, each TI group is either mapped directly to one frame orspread over PI frames. Each TI group is also divided into more than oneTI block (N_(TI)), where each TI block corresponds to one usage of atime interleaver memory. The TI blocks within the TI group may containslightly different numbers of XFECBLOCKs. Typically, the timeinterleaver may also function as a buffer for DP data prior to a processof frame building.

The Time interleaving according to an embodiment of the presentinvention is a twisted row-column block interleaver. The twistedrow-column block interleaver according to an embodiment of the presentinvention may column-wise write a first XFECBLOCK into a first column ofa TI memory, and a second XFECBLOCK into a next column, and so on).Then, in an interleaving array, cells are diagonal-wise readdiagonal-wise from a first row (rightwards along a row beginning with aleft-most column) to a last row, Nr cells are read out. Moreover, inorder to achieve single-memory deinterleaving at a receiver sideregardless of a number of XFECBLOCKs in a TI block the twistedrow-column block interleaver may insert the virtual XFECBLOCKs into theTI memory. The virtual XFECBLOCKs must be inserted infront of otherFECBLOCKS to achieve single-memory deinterleaving at a receiver side.

FIG. 9 illustrates a write operation of a time interleaver according toan embodiment of the present invention.

A left block in the figure illustrates a TI memory address array, andright blocks in the figure illustrate a write operation when two virtualFEC blocks and one virtual FEC block are inserted into heads of twocontiguous TI groups, respectively.

The frequency interleaver according to the present embodiment mayinclude an interleaving address generator for generating an interleavingaddress for applying corresponding data to a symbol pair.

FIG. 10 illustrates an interleaving address generator including a mainpseudo-random binary sequence (PRBS) generator and a sub-PRBS generatoraccording to each FFT mode which are included in a frequency interleaveraccording to an embodiment of the present invention.

(a) shows the block diagrams of the interleaving-address generator for8K FFT mode, (b) shows the block diagrams of the interleaving-addressgenerator for 16K FFT mode and (c) shows the block diagrams of theinterleaving-address generator for 32K FFT mode.

The interleaving process for the OFDM symbol pair is described asfollows, exploiting a single interleaving-sequence. First, availabledata cells (the output cells from the Cell Mapper) to be interleaved inone OFDM symbol O_(m,l) is defined as O_(m,l)=[x_(m,l,0), . . . ,x_(m,l,p), . . . , x_(m,l,Ndata-1)] for l=0, . . . , N_(sym)−1, wherex_(m,l,p) is the p^(th) cell of the l^(th) OFDM symbol in the m^(th)frame and N_(data) is the number of data cells: N_(data)=C_(FSS) for theframe signaling symbol(s), N_(data)=C_(data) for the normal data, andN_(data)=C_(FES) for the frame edge symbol. In addition, the interleaveddata cells are defined as P_(m,l)=[v_(m,l,0), . . . , v_(m,l,Ndata-1)]for l=0, . . . , N_(sym)−1.

For the OFDM symbol pair, the interleaved OFDM symbol pair is given byv_(m,l,Hi(p))=x_(m,l,p), p=0, . . . , N_(data)−1, for the first OFDMsymbol of each pair, v_(m,l,p)=x_(m,l,Hi(p)), p=0, . . . , N_(data)−1for the second OFDM symbol of each pair, where H₁(p) is the interleavingaddress generated based on a PRBS generator and a cyclic shift value(symbol offset) of a sub-PRBS generator.

As described above with reference to FIG. 6, a link layer is a layerbetween a physical layer and a network layer. And, a transmitter mayreceive data in the network layer and transport it to the physicallayer, and then, may transmit the data to a receiver by processing it inthe physical layer. A link layer processor may format input packets intoa single format packet so as to be processed in the physical layer. Inthe present disclosure, encapsulation and compression of the link layerperformed in the link layer may be performed based on ATSC Link layerProtocol (ALP), and the packets generated based on the ALP protocol maybe referred to as ALP packets. The link layer processor may receivenetwork layer data in a format such as IP data and MPEG-2 TS data, andmay encapsulate it into an ALP packet.

FIG. 11 illustrates a link layer packet according to an embodiment ofthe present invention.

In FIG. 11, a link layer packet, that is, an ALP packet includes a baseheader, an additional header, an optional header and a payload. The baseheader may have a fixed size and the additional header may have avariable size based on the base header. The additional header and theoptional header may include additional information/fields according tothe payload. An ALP packet header may include the additional headerbased on a control field of the base header. Whether the optional headeris present may be indicated by flag information included in theadditional header.

FIG. 12 illustrates a structure of a link layer packet in more detailaccording to an embodiment of the present invention.

In FIG. 12, a base header may include at least one field of a typefield, a Payload Configuration (PC) field, a header mode field in thecase that the PC field value is 0, a segmentation concatenation field inthe case that the PC field value is 1, or a length field.

An additional header may include at least one field of a length MSB (LenMSB) field, a Sub-stream Identifier Flag (SIF) field or a HeaderExtension Flag (HEF) in the case of a single packet. The additionalheader may include at least one field of a segment sequence number(Seg_SN) field, a Last Segment Indicator (LSI) field, an SIF field or anHEF field in the case of segmentation. The additional header may includeat least one field a length MSB (Len MSB) field, a count field, aSub-stream Identifier Flag (SIF) field or a component length field inthe case of concatenation).

An optional header may include an SID field and/or a header extensionfield. The Sub-stream Identifier (SID) field may indicate a sub-streamidentifier for an ALP packet. The SID may be used for filtering aspecific packet stream in a link layer level. The SID may be existedbetween the additional header and the optional header.

FIG. 13 illustrates a procedure for transmitting and receiving broadcastdata using an SID according to an embodiment of the present invention.

As described above, an ALP packet may include an SID. The SID may beused for filtering a specific packet stream. For example, as shown inFIG. 13, a packet stream that has a combination of the same IPaddress/port number may be represented as a single session. In thepresent disclosure, the packet stream that has a combination of the sameIP address/port number may be referred to as multicast. A session may bea set of data transmitted in a network or a network layer like an IP.

A transmitter may add a separate SID for the packet stream that has acombination of the same IP address/port number, and may include thecorresponding SID in a header of a link layer packet. However, in such acase, mapping information for each session and an SID should be able tobe signaled. In FIG. 13, for a first session and a second session thatare distinguished with IP/UDP, SIDs 0x01 and 0x02 may be allocated,respectively. A receiver may extract a PLP and may transport dataincluded in the PLP to an IP/UDP layer such that all of the dataincluded in the PLP are processed. However, in the case that the datacorresponding to a service required in the receiver is data of session1, the receiver performs filtering out the data of session 2, andaccordingly, it decreases processing burden. Accordingly, the receivermay process only the ALP packets of session 1 of which SID is 0x01, andmay transport it to the IP/UDP layer.

FIG. 14 illustrates link layer signaling information according to anembodiment of the present invention.

The service session information in FIG. 14(a) is the link layersignaling information for a receiver to receive a service. In FIG.14(a), the service session information includes a service number(num_services) field indicating the number of services, a service ID(service_id) field and service session information. The service sessioninformation may include a source IP address (source_IP_address) field, adestination IP address (destination_IP_address) field, a destinationport number (destination_port_number) field and a PLP ID field.

The service session information of FIG. 14(a) may further includesignaling information of FIG. 14(b). The signaling information of FIG.14(b) includes SID information in addition to service ID information.The receiver may combine session information for receiving a service andsub-stream mapping information, and may filter a stream for thecorresponding service by using the SID field included in a link layerpacket. That is, the receiver may perform a link layer filtering withthe SID that corresponds to a service ID.

Hereinafter, a method for classifying a data set, that is a sub-streamof a network layer. In a broadcast system, not all of functions providedby UDP/IP protocol, but only a part of the corresponding protocol may beused. As described with reference to FIG. 6, a transmitter may perform aheader compression in a link layer.

FIG. 15 illustrates an IPv4 packet header structure according to anembodiment of the present invention.

For an IPv4 packet header, the following classification may be applied.

1) A field having the same value at all times: Version (decimal number‘4’), IHL (decimal number ‘5’) and Protocol (decimal number ‘17’), 2) Afield for calculating a corresponding value in a receiver: Total lengthand Header Checksum, 3) Not used field: Type of service, Identification,IP flags, Fragment Offset and Time To Live (TTL)

FIG. 16 illustrates an IPv6 packet header structure according to anembodiment of the present invention.

For an IPv6 packet header, the following classification may be applied.

1) A field having the same value at all times: Version (decimal number‘6’) and Next Header (decimal number ‘17’), 2) A field for calculating acorresponding value in a receiver: Payload length, 3) Not used field:Traffic Class, Flow Label and Hop Limit

FIG. 17 illustrates a UDP packet header structure according to anembodiment of the present invention.

For a UDP packet header, the following classification may be applied.

1) A field having the same value at all times: Version (decimal number‘6’) and Next Header (decimal number ‘17’), 2) A field for calculating acorresponding value in a receiver: Length and Checksum

In the classification/condition described above, when a source addressand a destination address are transmitted in the case of an IP packet,and when a source port and a destination port are transmitted in thecase of a UDP packet, a receiver may reconstruct IP/UDP packet. Inaddition, in the case that IP address/port combination used in abroadcast stream is limited, the IP address/port is indexed, and onlythe corresponding index information may be transmitted. In this case,transmitter/receiver should know the index and the mapping informationfor IP address/port in advance.

FIG. 18 illustrates mapping information for an index and IP address/portnumber as link layer signaling information according to an embodiment ofthe present invention.

FIG. 18(a) illustrates information of signaling the mapping informationfor an index and IP address/port number for the case that a packet typeis IPv4. FIG. 18(b) illustrates information of signaling the mappinginformation for an index and IP address/port for the case that a packettype is IPv6.

In the case that header compression is performed under a specificcondition, compression information may be mapped to an index value. Inthis case, in order to inform the header compression information to areceiver, a predefined mapping table should be stored in the receiver.However, in this case, the session information that may be used for abroadcast data transmission, that is, a use of IP address/port numbermay be restricted. Furthermore, in the case that a separate index isused for each channel and each PLP, large storage space is required inthe receiver in order to store the corresponding index. Hereinafter, amethod for transmitting such an index as signaling information isproposed, and particularly, a method is proposed for minimizing anoccurrence of overhead owing to a use of the signaling information whichis transmitted for a link layer configuration.

In FIG. 14(a), an embodiment of session information for a service isshown. A receiver should receive transmission information of acorresponding service data in order to obtain a specific service.Hereinafter, an embodiment for adding mapping information to the sessioninformation described in FIG. 14(a) is described.

FIG. 19 illustrates mapping information according to an embodiment ofthe present invention.

FIG. 19 relates to a case of single session in which a service istransmitted through a single session, and the mapping information ofFIG. 19 may be Sub stream and Header compression Mapping (SHM) signalinginformation.

In FIG. 19, a Header Compression Flag (HCF) is a flag that informswhether a header compression is applied. As an embodiment, in the casethat the HCP field value is 1, this represents that the headercompression is applied. The HCF may be used for adding information whichis not defined in the service session information among an IP addressand a port number in relation to a service ID. As an embodiment, in thecase that all of source/destination IP address and source/destinationport number are defined in the service session information, the HCF maynot be used.

When the signaling information of FIG. 19 is transmitted, a link layerprocessing operation of a receiver is as follows.

When a user selects a specific service, a receiver may obtain theservice session information for the corresponding service ID. Thereceiver may obtain the service session information by parsing ALPsignaling information. Accordingly, the receiver may obtain a PLP forthe corresponding service ID, a source IP address, a destination IPaddress and a destination port number.

The receiver may obtain SHM signaling information for the correspondingservice ID. The receiver may obtain a fact on whether a headercompression is performed for the corresponding service ID, an SID and asource port number by parsing the SHM signaling information. Thereceiver may decode a PLP that corresponds to a service ID, and mayfilter a packet that has an SID of a reception service among the linklayer packets included in the PLP. The receiver may restore IP/UDPpacket header by using the IP address/port number that corresponds tothe SID from the filtered packets. And the receiver may transport theIP/UDP packet in which the header is restored to a higher layer.

FIG. 20 illustrates mapping information according to an embodiment ofthe present invention.

FIG. 20 relates to the case of a single session in which a service istransmitted through a single session, and particularly, shows anembodiment of the case that the mapping information of FIG. 19 isincluded in service session information. In FIG. 20, the description forthe field/information described in FIG. 19 is not repeated.

In the case that the signaling information of FIG. 20 is transmitted, alink layer processing operation of a receiver is as below.

When a user selects a specific service, a receiver may obtain servicesession information for the corresponding service ID. The receiver mayobtain the service session information by parsing ALP signalinginformation. Accordingly, the receiver may obtain a PLP for thecorresponding service ID, a source IP address, a destination IP address,a destination port number, a fact on whether a header compression isperformed for the corresponding service ID, an SID and a source portnumber.

The receiver may decode the PLP that corresponds to the service ID, andmay filter a packet that has an SID of a reception service among thelink layer packets included in the PLP. The receiver may restore IP/UDPpacket header by using the IP address/port number that corresponds tothe SID from the filtered packets. And the receiver may forward theIP/UDP packet in which the header is restored to a higher layer.

Hereinafter, the case that a service is transmitted through severalsessions is described. According to a session in which each service istransmitted, each SID may be mapped, and a stream transmitted through aplurality of sessions is mapped to a separate sub-stream, and aplurality of sub-stream information may be used for receiving thecorresponding service.

FIG. 21 illustrates service session information according to anembodiment of the present invention.

FIG. 21 shows service session information for an embodiment in which asingle service is transmitted through a plurality of sessions.

The different point from the service session information shown in FIG.14(a) is that a service session number (num_service_session) field for aplurality of service sessions and for loop for a plurality of servicesessions are added.

FIG. 22 illustrates mapping information according to an embodiment ofthe present invention.

FIG. 22 shows the mapping information for an embodiment in which asingle service is transmitted through a plurality of sessions. Themapping information in FIG. 22 may be Sub stream and Header compressionMapping (SHM) signaling information. In relation to FIG. 22, the samedescription for the field description described above is not repeated.

In the case that the service session information of FIG. 21 and the SHMsignaling information of FIG. 22 are used, a link layer processingoperation of a receiver is as below.

When a user selects a specific service, a receiver may obtain theservice session information for the corresponding service ID. Thereceiver may obtain the service session information by parsing ALPsignaling information. The receiver may obtain a plurality of sessioninformation for a single service. Accordingly, the receiver may obtain aPLP for a plurality of sessions, a source IP address, a destination IPaddress and a destination port number.

The receiver may obtain SHM signaling information for the correspondingservice ID. In the SHM information, a separate SID may be allocated toeach session that configures a service. The receiver may obtain a facton whether a header compression is performed for the correspondingsession, an SID and a source port number by parsing the SHM signalinginformation. In order to allocate a separate SID to each session, adestination IP address and a port number may be additionally included ineach signaling table.

The receiver may decode a PLP for a plurality of sessions, and mayfilter a packet that has an SID of a reception service among the linklayer packets included in the PLP. The receiver may restore IP/UDPpacket header by using the IP address/port number that corresponds tothe SID from the filtered packets. And the receiver may forward theIP/UDP packet in which the header is restored to a higher layer.

FIG. 23 illustrates mapping information according to an embodiment ofthe present invention.

FIG. 23 shows the mapping information for an embodiment in which asingle service is transmitted through a plurality of sessions. FIG. 23shows an embodiment of the case that the mapping information of FIG. 22is included in the service session information. In FIG. 23, the samedescription for the field/information described in FIG. 22 is notrepeated.

In the case that the signaling information of FIG. 23 is transmitted, alink layer processing operation of a receiver is as below.

When a user selects a specific service, a receiver may obtain theservice session information for the corresponding service ID. Thereceiver may obtain the service session information by parsing ALPsignaling information. The receiver may obtain a plurality of sessioninformation and a corresponding SID for a single service. Accordingly,the receiver may obtain a PLP for a plurality of sessions, a source IPaddress, a destination IP address, a destination port number, a fact onwhether a header compression is performed for the corresponding serviceID, an SID and a source port number. In order to allocate a separate SIDto each session, a destination IP address and a port number may beadditionally included in each signaling table.

The receiver may decode a PLP for a plurality of sessions, and mayfilter a packet that has an SID of a reception service among the linklayer packets included in the PLP. The receiver may restore IP/UDPpacket header by using the IP address/port number that corresponds tothe SID from the filtered packets. And the receiver may forward theIP/UDP packet in which the header is restored to a higher layer.

FIG. 24 illustrates a link layer processing of transmitter/receiveraccording to an embodiment of the present invention.

FIG. 24(a) shows a link layer processing of a transmitter and FIG. 24(b)shows a link layer processing of a receiver.

In FIG. 24(a), a transmitter transmits IP/UDP packet stream thatcorresponds to service A to session #1 and session #2. A link layerprocessor may encapsulate session #1 and session #2 with different linklayer packets, respectively. While the transmitter performs a link layerprocessing, the transmitter may map SID 0x01 and SID 0x02 to session #1and session #2, respectively, and may process a link layer packet withPLP data.

In FIG. 24(b), a receiver receives a PLP and performs a link layerprocessing. When a user selects service A, the receiver is not requiredto other data (SID=0x03, 0x04) included in a link layer. Accordingly,the receiver may check the SID that corresponds to service A fromsignaling information, and may filter the packet that has thecorresponding SID (0x01 and 0x02) and transport it to IP/UDP layer.

FIG. 25 illustrates mapping information according to an embodiment ofthe present invention.

The mapping information in FIG. 25 may be Sub stream and Headercompression Mapping (SHM) information.

In the case that a service is transmitted through several sessions, theservice session information as shown in FIG. 21 may be transmitted. Inthis case, each service may be mapped to a single SID or a streamtransmitted through several sessions may be mapped to a singlesub-stream. In such a case, a field may be added to inform theinformation for a header compression additionally.

In the Sub stream and Header compression Mapping (SHM) information ofFIG. 25, an HC index (HC_index) information is added to the mappinginformation of FIG. 22. Other description is the same as describedabove.

In the case that the information of FIG. 25 is used, an operation of areceiver is as below.

When a user selects a specific service, a receiver may obtain servicesession information for the corresponding service ID. The receiver mayobtain the service session information by parsing ALP signalinginformation. The receiver may obtain a PLP for a plurality of sessions,a source IP address, a destination IP address and a destination portnumber.

The receiver may obtain SHM signaling information for the correspondingservice ID. In the SHM information, a separate SID may be allocated toeach session that configures a service. The receiver may obtain a facton whether a header compression is performed for the correspondingsession, an SID and a source port number by parsing the SHM signalinginformation. In the case that the header compression is applied, thereceiver may obtain the corresponding HC_Index information and/or asource port number.

The receiver may decode a PLP for a plurality of sessions, and mayfilter a packet that has an SID of a reception service among the linklayer packets included in the PLP. The receiver may restore IP/UDPpacket header by using the HC_Index information and the IP address/portnumber that corresponds to the SID from the filtered packets. And thereceiver may transport the IP/UDP packet in which the header is restoredto a higher layer.

FIG. 26 illustrates service session information according to anembodiment of the present invention.

The service session information in FIG. 26 shows an embodiment of thecase that the SHM information is included in the service sessioninformation.

In the case that the information of FIG. 26 is used, an operation of areceiver is as below.

When a user selects a specific service, a receiver may obtain servicesession information for the corresponding service ID. The receiver mayobtain the service session information by parsing ALP signalinginformation. The receiver may obtain a PLP for a plurality of sessions,a source IP address, a destination IP address, a destination portnumber, a fact on whether a header compression is performed for thecorresponding session, an SID and a source port number. In the case thatthe header compression is applied, the receiver may obtain thecorresponding HC_Index information and/or a source port number.

The receiver may decode a PLP for a plurality of sessions, and mayfilter a packet that has an SID of a reception service among the linklayer packets included in the PLP. The receiver may restore IP/UDPpacket header by using the HC_Index information and the IP address/portnumber that corresponds to the SID from the filtered packets. And thereceiver may transport the IP/UDP packet in which the header is restoredto a higher layer.

FIG. 27 illustrates a link layer processing of transmitter/receiveraccording to an embodiment of the present invention.

FIG. 27(a) shows a link layer processing of a transmitter and FIG. 27(b)shows a link layer processing of a receiver.

In FIG. 27(a), a transmitter transmits IP/UDP packet stream thatcorresponds to service A to session #1 and session #2. A link layerprocessor may encapsulate session #1 and session #2 with different linklayer packets, respectively. While the transmitter performs a link layerprocessing, the transmitter may map SID 0x01 and SID 0x02 to session #1and session #2, respectively, and may process a link layer packet withPLP data. In addition, the transmitter may allocate a header compressionindex (HC_ID) when the header compression is performed.

In FIG. 27(b), a receiver receives a PLP and performs a link layerprocessing. When a user selects service A, the receiver is not requiredto other data (SID=0x03, 0x04) included in a link layer. Accordingly,the receiver may check the SID and the HC index that correspond toservice A from signaling information, and may filter the packet that hasthe corresponding SID (0x01 and 0x02) and forward it to IP/UDP layer.

FIG. 28 illustrates link layer mapping information according to anembodiment of the present invention.

FIG. 28 may provide a mapping of a PLP and IP/UDP, that is, a linkmapping of an upper layer and a physical layer. The information of FIG.28 may be referred to as sub stream mapping information, link layermapping information or link mapping information. The information of FIG.28 may be added to the service session information described above.

The mapping information of FIG. 28 includes PLP number (num_PLP)information, and includes PLP ID information with respect to theincluded PLPs and IP address/port number information mapped to thecorresponding PLP ID. The mapping information of FIG. 28 includes numberinformation (num_sub_stream) of sub stream, that is, a session includedin a PLP. And, with respect to each sub stream, SID information, sourceIP address (Src_address) information, destination IP address(Dest_address) information, source port (Src_port) information anddestination port (Dest_port) information.

As shown in FIG. 28, the sub stream included in a PLP may be identifiedby the source IP address (Src_address) information, the destination IPaddress (Dest_address) information, the source port (Src_port)information and the destination port (Dest_port) information.Furthermore, such a sub stream may be identified by an SID.

A receiver may filter a stream for a service by using a combination ofupper layer session information and sub stream mapping information forreceiving the service and the SID field included in a link layer packet.

Hereinafter, in FIG. 29 to FIG. 32, it is described a signalingstructure that indicates each PLP and an SID included in thecorresponding PLP and an operational structure of transmitter/receiverfor the structure.

FIG. 29 illustrates an operational structure of a transmitter accordingto an embodiment of the present invention.

In IP/UDP network layer, an IP/UDP session which is group/set of IP/UDPdata for a specific service may be identified by an IP address and/or aUDP port. A link layer of the transmitter may map an IP/UDP session to aPLP, and may provide the mapping information as shown in FIG. 28.

The transmitter may perform a sub stream mapping to a session. That is,the transmitter may allocate a sub stream ID (SID) to a specificsession. The mapping between a sub stream and a session may be providedthrough sub stream mapping information as an SID. Furthermore, thesession to which the SID is allocated is encapsulated in a link layerand transported to a PLP. In the case that an IP stream which is goingto be transmitted to each PLP is multiplexed and transported to a linklayer, the transmitter may generate the corresponding sessioninformation (a source IP address, a destination IP address, a sourceport number and a destination port number), a PLP ID and the informationmapped to an SID as signaling, and may encapsulate and transport it as alink layer signaling packet.

FIG. 30 illustrates an operational structure of a receiver according toan embodiment of the present invention.

The embodiment of FIG. 30 shows the case of receiving data by obtainingpath information of a service that is going to be received through asignaling like a service list table at one time.

When a user selects a specific service, a receiver may obtain PLPinformation that is going to be received through a signaling like aservice list table for the corresponding service. The receiver mayobtain service session information (a PLP, a source IP address, adestination IP address and a destination port number) through the aservice list table. The receiver may receive a link layer packet from adecoded PLP and may obtain signaling information (e.g., sub streammapping information) in which SID information is included. The receivermay obtain mapping relation information between an SID and sessioninformation/data by using the mapping information.

The receiver may identify an SID for an IP address and a port number ofa service to be received. A link layer processor of the receiver mayfilter only the packet for the corresponding SID and transport it to ahigher layer, that is, IP/UDP layer, and may not process the packetsthat have remaining SIDs. A higher layer processor of the receiver mayprocess the received IP/UDP packets and provide a selected service.

FIG. 31 illustrates an operational structure of a receiver according toanother embodiment of the present invention.

The embodiment of FIG. 31 shows the case of receiving data by obtainingpath information of a service that is going to be received through asignaling like a service list table, and obtaining additional signaling(e.g., service layer signaling), and receiving data for another path.

When a user selects a specific service, a receiver may obtain PLPinformation and session information that are going to be receivedthrough a signaling like a service list table for the correspondingservice. The receiver may obtain service session information (a PLP, asource IP address, a destination IP address and a destination portnumber) through the a service list table. The receiver may receive alink layer packet from a decoded PLP and may obtain signalinginformation (e.g., sub stream mapping information) in which SIDinformation is included. The receiver may obtain mapping relationinformation between an SID and session information/data by using themapping information. The receiver may identify an SID for an IP addressand a port number of a service to be received. A link layer processor ofthe receiver may filter only the packet for the corresponding SID andtransport it to a higher layer, that is, IP/UDP layer, and may notprocess the packets that have remaining SIDs.

The receiver may obtain a signaling (e.g., service layer signaling) inwhich there is path information for other data to receive among thereceived data, and may obtain PLP information and session information tobe additionally received. Furthermore, the receiver may receive a linklayer packet from the PLP which is additionally decoded, and may obtainthe signaling (e.g., service layer signaling) in which SID informationis included. Even in this case, the receiver may identify an SID for anIP address and a port number of a service to be received, and may filteronly the packet for the corresponding SID and transport it to a higherlayer, that is, IP/UDP layer.

A higher layer process of the receiver may process the received IP/UDPpackets and provide a selected service.

FIG. 32 illustrates mapping information according to an embodiment ofthe present invention.

As an embodiment, the sub stream mapping information shown in FIG. 32may be forwarded through each PLP. Since separate table is transmittedto each PLP, it may be considered that the PLP in which a table isincluded and the PLP in which data is included may have the same PLP_ID.

Hereinafter, in FIG. 33 to FIG. 35, it is described a signalingstructure in which SID information that corresponds to each PLP istransmitted to separate signaling PLP and signaling PLP indicates an SIDof several PLPs, and an operational structure of transmitter/receiverfor the structure.

FIG. 33 illustrates an operational structure of a transmitter accordingto an embodiment of the present invention.

In IP/UDP network layer, an IP/UDP session which is group/set of IP/UDPdata for a specific service may be identified by an IP address and/or aUDP port. A link layer of the transmitter may map an IP/UDP session to aPLP, and may provide the mapping information as shown in FIG. 33.

The transmitter may perform a sub stream mapping to a session. That is,the transmitter may allocate a sub stream ID (SID) to a specificsession. The mapping between a sub stream and a session may be providedthrough sub stream mapping information as an SID. Furthermore, thesession to which the SID is allocated is encapsulated in a link layerand transport to a PLP.

In the case that an IP stream which is going to be transmitted to eachPLP is multiplexed and forwarded to a link layer, the transmitter maygenerate the corresponding session information (a source IP address, adestination IP address, a source port number and a destination portnumber), a PLP ID and the information mapped to an SID as signaling, andmay encapsulate and transport it as a link layer signaling packet.Particularly, FIG. 33 shows an embodiment that a link layer signalingpacket for a plurality of PLPs (PLP1 to PLPM) is not included in eachPLP, but included in a specific PLP (signaling PLP).

FIG. 34 illustrates an operational structure of a receiver according toan embodiment of the present invention.

The embodiment of FIG. 34 shows the case of receiving data by obtainingpath information of a service that is going to be received through asignaling like a service list table at one time.

When a user selects a specific service, a receiver may obtain PLPinformation that is going to be received through a signaling like aservice list table for the corresponding service. The receiver mayobtain service session information (a PLP, a source IP address, adestination IP address and a destination port number) through the aservice list table. The receiver may receive a link layer packet from adecoded PLP or other specific PLP (signaling PLP or common PLP) and mayobtain signaling information (e.g., sub stream mapping information) inwhich SID information for all PLPs is included. The receiver may obtainmapping relation information between an SID and session information/databy using the mapping information.

The receiver may identify an SID for an IP address and a port number ofa service to be received. A link layer processor of the receiver mayfilter only the packet for the corresponding SID and forward it to ahigher layer, that is, IP/UDP layer, and may not process the packetsthat have remaining SIDs. A higher layer processor of the receiver mayprocess the received IP/UDP packets and provide a selected service.

FIG. 35 illustrates an operational structure of a receiver according toanother embodiment of the present invention.

The embodiment of FIG. 35 shows the case of receiving data by obtainingpath information of a service that is going to be received through asignaling like a service list table, and obtaining additional signaling(e.g., service layer signaling), and receiving data for another path.

When a user selects a specific service, a receiver may obtain PLPinformation and session information that are going to be receivedthrough a signaling like a service list table for the correspondingservice. The receiver may obtain service session information (a PLP, asource IP address, a destination IP address and a destination portnumber) through the a service list table. The receiver may receive alink layer packet from a decoded PLP or other specific PLP (signalingPLP or common PLP) and may obtain signaling information (e.g., substream mapping information) in which SID information for all PLPs isincluded.

The receiver may obtain mapping relation information between an SID andsession information/data by using the mapping information. The receivermay identify an SID for an IP address and a port number of a service tobe received. A link layer processor of the receiver may filter only thepacket for the corresponding SID and transport it to a higher layer,that is, IP/UDP layer, and may not process the packets that haveremaining SIDs.

The receiver may obtain a signaling (e.g., service layer signaling) inwhich there is path information for other data to receive among thereceived data, and may obtain PLP information and session information tobe additionally received. Furthermore, the receiver may receive a linklayer packet from the PLP which is additionally decoded, and may obtainthe signaling (e.g., service layer signaling) in which SID informationis included. Even in this case, the receiver may identify an SID for anIP address and a port number of a service to be received, and may filteronly the packet for the corresponding SID and transport it to a higherlayer, that is, IP/UDP layer.

A higher layer processor of the receiver may process the received IP/UDPpackets and provide a selected service.

As an embodiment, the sub stream mapping information as shown in FIG. 28may be forwarded through a signaling PLP or a common PLP. In order tosignal the SID for each PLP, the SID information may be provided foreach PLP_ID. In the present disclosure, signaling PLP indicates a PLPthat includes signaling information.

Hereinafter, a header compression method of a link layer described aboveis described in more detail.

RoHC-U scheme may be used for an IP header compression in a link layer.As an embodiment, profile 0x02 of RoHC-U may be applied to a broadcastsystem of the present invention. The link layer header compression ofthe present invention may further include an adaptation procedure of anadaptation module. A link layer processor may include an RoHC module andthe adaptation module, and an encapsulator.

The adaptation module may extract context information from an RoHCpacket stream. The context information may include at least one of astatic chain and a dynamic chain. The adaptation module may convert anIR packet and/or an IR-DYN packet into a compressed packet. In addition,the adaptation module may generate signaling information for RoHC-Ucompression, and the signaling information may be transmitted as linklayer signaling information.

An advantage of the adaptation module is the fact that fast packetstream detection is available. Particularly, in relation to a channelchange, packet stream detection becomes faster. A receiver is notrequired to wait for detection of an IR packet in an original RoHCdecompressor. The receiver may detect signaling information and releasecompression of a packet stream in any time. For a stable IP stream, aperiod of an IR packet generation may be elongated. However, a signalingPLP should be transmitted in more robustly than a data PLP. An RoHCcompressor may also be referred to as an IP header compressor or aheader compressor.

Adaptation may be applied as a plurality of modes.

FIG. 36 illustrates an IP header compression of a first adaptation modeaccording to an embodiment of the present invention.

A first adaptation mode represents a mode in which an adaptationoperation is skipped during a header compression procedure of an IPstream.

A link layer processor of a transmitter performs an IP headercompression of a reception IP stream. An RoHC module may compress anIP/UDP packet and may output an IR packet, an IR-DYN packet and acompressed packet. In the first adaptation mode, an adaptation modulemay bypass the received packets, not extract context information fromthe received IR packet and IR-DYN packet. And, the link layer processormay encapsulate the received packet into an ALP packet. A packet typevalue of the encapsulated packets may be a value indicating a compressedIP packet.

FIG. 37 illustrates a transmission operation of a first adaptation modeaccording to an embodiment of the present invention.

In FIG. 37, an RoHC compressor may initialize a context for an initialIP packet, and may generate an IR packet. In addition, when a context isupdated, the RoHC compressor generates an IR-DYN packet. A staticcontext is kept until the next IP packet is generated. A dynamic contextis kept until the next IR packet or an IR-DYN packet is generated. In afirst adaptation mode, packet conversion and context extraction are notoccurred.

FIG. 38 illustrates a reception operation of a first adaptation modeaccording to an embodiment of the present invention.

In FIG. 38, a RoHC decompressor receives a packet stream. The RoHCdecompressor may decompress subsequent packets only in the case thatthere is an IR packet. Accordingly, all packets before the IP packet isdecompressed are discarded.

FIG. 39 illustrates an IP header compression of a second adaptation modeaccording to an embodiment of the present invention.

In a second adaption mode, an adaptation module may convert an IR packetinto an IR-DYN packet by extracting context information in the IRpacket.

A link layer processor of a transmitter performs an IP headercompression of a reception IP stream. An RoHC module may compress anIP/UDP packet and may output an IR packet, an IR-DYN packet and acompressed packet. In the second adaptation mode, an adaptation moduleextracts context information from the received IR packet, and convertsthe IP packet into an IR-DYN packet. And, the link layer processor mayencapsulate the received packet into an ALP packet.

The extracted context information may be transmitted by a link layersignaling. And, such context information may be encapsulated into apacket which is separate from a data part. A packet type value ofpackets of which context information is encapsulated may be a valueindicating a link layer signaling packet. On the other hand, a packettype value of other encapsulated packets may be a value indicating acompressed IP packet.

FIG. 40 illustrates a transmission operation of a second adaptation modeaccording to an embodiment of the present invention.

In FIG. 40, an RoHC compressor may initialize a context for an initialIP packet, and may generate an IR packet. In addition, when a context isupdated, the RoHC compressor generates an IR-DYN packet. A staticcontext is kept until the next IP packet is generated. A dynamic contextis kept until the next IR packet or an IR-DYN packet is generated.

In a second adaptation mode of FIG. 40, an adaptation module may extractcontext information including a static chain from an IR packet, and mayconvert the IP packet into an IR dynamic packet.

FIG. 41 illustrates a reception operation of a second adaptation modeaccording to an embodiment of the present invention.

In FIG. 41, an adaptation module receives a packet stream. A receivermay obtain static context information by processing a signaling PLP. Theobtainment of the context information may also be performed before aprocessing of a data PLP or a packet stream. The adaptation module mayconvert a detected IR-DYN packet into an IR packet by using the staticcontext information.

RoHC decompressor/RoHC-U module receive a packet stream. The RoHCdecompressor may decompress subsequent packets only in the case thatthere is an IR packet. The RoHC decompressor may decompress the packetsfollowing the IR packet converted in the adaptation module.

In a second adaptation mode of FIG. 41, an interval between an initialreception and a packet decompressing is reduced, and accordingly,discarded packets are also reduced. This is because decompressing isable to be started by converting an IR-DYN packet into an IR packet byusing context information only in the case that an IR-DYN packet isdiscovered, even before an initial IR packet is discovered, in thesecond adaptation mode. However, even in the case of the secondadaptation mode, latency may occur until reception/discovery of anIR-DYN packet.

All RoHC packets may include a sequence number. By using the sequencenumber, a context and a compressed packet may be combined. The secondadaptation mode may be suitable for an IP stream which is dynamicallyconverted.

FIG. 42 illustrates an IP header compression of a third adaptation modeaccording to an embodiment of the present invention.

In a third adaption mode, an adaptation module may convert an IR packetand an IR-DYN packet into compressed packets by extracting contextinformation in the IR packet and the IR-DYN packet. A link layerprocessor may include an RoHC module, an adaptation module and anencapsulator.

A link layer processor of a transmitter performs an IP headercompression of a reception IP stream. An RoHC module may compress anIP/UDP packet and may output an IR packet, an IR-DYN packet and acompressed packet. In the third adaptation mode, an adaptation moduleconverts an IR packet and an IR-DYN packet into compressed packets byextracting context information from the received IR packet and IR-DYNpacket. And, the link layer processor may encapsulate the receivedpacket into an ALP packet.

The extracted context information may be transmitted by a link layersignaling. And, such context information may be encapsulated into apacket which is separate from a data part. A packet type value ofpackets of which context information is encapsulated may be a valueindicating a link layer signaling packet. On the other hand, a packettype value of other encapsulated packets may be a value indicating acompressed IP packet.

FIG. 43 illustrates a transmission operation of a third adaptation modeaccording to an embodiment of the present invention.

In FIG. 43, an RoHC compressor may initialize a context for an initialIP packet, and may generate an IR packet. In addition, when a context isupdated, the RoHC compressor generates an IR-DYN packet. A staticcontext is kept until the next IP packet is generated. A dynamic contextis kept until the next IR packet or an IR-DYN packet is generated.

In a third adaptation mode of FIG. 43, an adaptation module may extractcontext information including a static chain from an IR packet, and mayextract context information including a dynamic chain from an IR-DYNpacket. And, the adaptation module may convert the IP packet and theIR-DYN packet into compressed packets.

FIG. 44 illustrates a reception operation of a second adaptation modeaccording to an embodiment of the present invention.

In FIG. 44, an adaptation module receives a packet stream. A receivermay obtain context information by processing a signaling PLP. Theobtainment of the context information may also be performed before aprocessing of a data PLP or a packet stream. The adaptation module mayconvert the compressed packet into an IR packet by using the contextinformation. In addition, the adaptation module may convert thecompressed packet into an IR-DYN packet by using the contextinformation. When the compressed packet is converted into an IR packet,a static chain may be used, and when the compressed packet is convertedinto an IR-DYN packet, a dynamic chain may be used.

RoHC decompressor/RoHC-U module receive a packet stream. The RoHCdecompressor may decompress subsequent packets only in the case thatthere is an IR packet. The RoHC decompressor may decompress the packetsfollowing the IR packet converted in the adaptation module.

In a second adaptation mode of FIG. 44, an interval between an initialreception and a packet decompressing is reduced, and accordingly,discarded packets are also reduced. This is because decompressing isable to be started by converting an arbitrary reception packet into anIR packet by using context information, in the second adaptation mode.

All RoHC packets may include a sequence number. By using the sequencenumber, a context and a compressed packet may be combined. In a thirdadaptation mode, by using context information, fast decompressing may beperformed for any compressed packet. When a static IP stream iscompressed, an IR packet and an IR dynamic packet are not frequentlygenerated. Accordingly, the third adaptation mode may be suitable for astatic IP stream.

In the case of the first adaptation mode, an adaptation is bypassed andadditional signaling is not generated. Accordingly, a simple operationis available. However, a receiver is needed to detect an IR packet for adecompression. It may be preferable that the first adaptation mode isused for a stable IP stream in which an IP packet is not frequentlygenerated.

In the case of the second adaptation mode, an adaptation module isneeded to convert an IR packet into an IR-DYN packet, and a staticcontext should be signaled. Accordingly, a dynamic operation isavailable. A receiver should detect an IR-DYN packet for adecompression. It may be preferable that the second adaptation mode isused for a stable IP stream in which an IR DYN packet is not frequentlygenerated. Since a context is frequently changed, a decompressor shouldfrequently update context information.

In the case of the third adaptation mode, an adaptation module is neededto convert an IR packet and an IR-DYN packet into a compressed packet,and static and dynamic context should be signaled. Accordingly, fastdecompression start is available. However, in the third mode, an amountof signaling information may be increased in comparison with the othermodes. It may preferable that the third adaptation mode is applied to astatic IP stream.

FIG. 45 illustrates RoHC-U Description Table (RDT) information accordingto an embodiment of the present invention.

FIG. 45 shows an embodiment of signaling information that transmitscontext information which is generated according to an operation of anadaptation module. The RDT information of FIG. 45 includes at least oneof static chain information or dynamic chain information.

In FIG. 45, a PLP ID field may be used in the case that all types ofcontext signaling is transmitted through the same PLP. A context IDfield may be applied to a multiple IP stream. A context profile(context_profile) field may be omitted in the case that there is asingle profile.

A dynamic chain presence (dynamic_chain_present) field may indicatewhether this table includes a dynamic chain. That is, this field mayindicate whether the third adaption mode is applied.

A sequence number (sequence_number) field may be used for synchronizingbetween context information and a compressed packet. That is, this fieldmay be used for the case that the third adaption mode is applied.

A static chain byte field and a dynamic chain byte field are as definedin the standard in relation to ROHC compression (RFC 3095).

FIG. 46 illustrates a broadcast signal transmitter and a broadcastsignal receiver according to an embodiment of the present invention.

A broadcast signal transmitter 46100 includes a link layer processor46110 and a physical layer processor 46120.

The link layer processor 46110 may perform a link layer processing ofIP/UDP data. The link layer processor may further include a headercompressing module, an adaptation module and an encapsulating module.The link layer processor 46100 may perform the link layer processingdescribed in relation to FIG. 6 to FIG. 7 and FIG. 11 to FIG. 45.

The physical layer processor 46120 may perform a physical layerprocessing of a link layer packet based on a PLP. The physical layerprocessor 46120 may perform the physical layer processing described inrelation to FIG. 8 to FIG. 10.

A broadcast signal receiver 46200 includes a receiver side link layerprocessor 46210 and a physical layer processor 46220.

The receiver side physical layer processor 46220 may obtain signalinginformation by processing a PLP includes signaling information. Inaddition, the physical layer processor 46220 may obtain a link layerpacket by processing a PLP that corresponds to a service based on thesignaling information. The receiver side physical layer processor 46220may perform an operation that corresponds to an inverse process of thetransmitter side physical layer processor 46120.

The receiver side link layer processor 46210 may receive a link layerpacket from a processed PLP, and may reconstruct IP/UDP data byprocessing the link layer packet. The receiver side link layer processor46210 may perform an operation that corresponds to an inverse process ofthe transmitter side link layer processor 46110. The operation of thereceiver side link layer processor 46210 is as described in relation toFIG. 6 to FIG. 7 and FIG. 11 to FIG. 45.

FIG. 47 illustrates a broadcast signal transmission method according toan embodiment of the present invention.

A broadcast transmitter may perform a link layer processing of IP/UDPdata (step, S47010). The broadcast transmitter may link layer processingIP/UDP data to output a link layer packet. The broadcast transmitter mayencapsulate IP/UDP data and link layer signaling information into aseparate link layer packet. In the present disclosure, IP/UDP data andIP/UDP stream may also be referred to IP data and IP sub stream,respectively.

The broadcast transmitter may perform a physical layer processing of alink layer packet based on a PLP (step, S47020). The physical layerprocessing operation using a physical layer processor of the broadcasttransmitter is as described in relation to FIG. 8 above.

A link layer packet may include at least one of a base header, anadditional header, an optional header or a payload. The optional headermay include Sub-stream ID (SID) information that identifies a specificIP/UDP sub-stream included in a link layer packet. The specific IP/UDPsub-stream represents a specific data set identified in IP/UDP networklayer, and an IP/UDP sub-stream may be identified by a source IP addressinformation, destination IP address information, source UDP portinformation and destination UDP port information. An additional headerof a link layer packet may include flag information that indicateswhether SID information is included in an optional header.

The link layer signaling information includes mapping information for aPLP and IP/UDP data carried in a PLP. The mapping information includesPLP number information, IP/UDP sub-stream number information included ina PLP, source IP address information for each IP/UDP sub-stream,destination IP address information, source UDP port information,destination UDP port information and SID information for IP/UDPsub-stream. The SID information may be used for filtering IP/UDPsub-stream included in a PLP in a link layer level.

The link layer processing step may further include step of compressingan IP header of an IP/UDP packet and generating at least one of an IRpacket, an IR-DYN packet or a compressed packet and adapting step forselectively converting compressed IP/UDP packet. The adaptation step mayoperate in a plurality of operational modes. The operational mode of theadaptation step includes the first adaptation mode in which an IRpacket, an IR-DYN packet and a compressed packet are bypassed, thesecond adaptation mode in which context information of an IR packet isextracted and an IR packet is converted into the IR-DYN packet and thethird adaptation mode in which context information of an IR packet andan IR-DYN packet is extracted and the IR packet and the IR-DYN packetare converted into a compressed packet.

The link layer signaling information includes description informationfor such an IP header compression. The description information mayinclude context information which is extracted in the adaptation step.

The link layer signaling packet may be included in a PLP that forwards aservice list table. The service list table is signaling information thatdescribes a service as described above in relation to FIG. 3.

According to the present invention, an ID is added for identifying dataof IP/UDP layer, that is, a sub-stream in a link layer and signaled, andaccordingly, a waste of processing may be prevented, which decodes allof unnecessary data in a receiver side. Particularly, such a signalingis supported in a unit of PLP, and a link layer processing may beperformed in accordance with a physical layer processing. It may besignaled whether there is an SID in an additional header such that theSID may be added in a link layer packet header as occasion demands.

According to the present invention, an adaptation may be performed in apacket of which header is compressed. Context information is extractedand separately signaled through the adaptation, and accordingly, even inthe case of abrupt change like a channel change, a receiver may processdata with smaller delay. However, signaling overhead may be increased,and adaptation mode may be differently applied according to the type ofdata in which context information is generated. That is, for staticIP/UDP data of which context information is small originally, the thirdadaption mode may be applied. For IP/UDP data which is dynamicallychanged, the second adaptation mode may be applied. On the other hand,in the case that there are enough channels and processing performance isgood, the third adaptation may be used, and in the case that there isnot enough channels, the first adaption mode may be used.

The link layer signaling information may be included in a PLP thatforwards a service list table. Accordingly, a receiver side physicallayer processor is able to obtain link layer signaling information whileparsing a PLP that includes the service list table, a receiver sideprocessing time may be reduced.

The steps described in the aforementioned embodiments can be performedby hardware/processors. Modules/blocks/units described in the aboveembodiments can operate as hardware/processors. In addition, the methodsproposed by the present invention can be executed as a code. Such codecan be written on a processor-readable storage medium and thus can beread by a processor provided by an apparatus.

While the embodiments have been described with reference to respectivedrawings for convenience, the embodiments may be combined to implement anew embodiment. The apparatus and method according to the presentinvention are not limited to the configurations and methods of theabove-described embodiments and the whole or some of the embodiments maybe selectively combined to obtain various modifications.

Meanwhile, the method proposed in the present invention may beimplemented as processor-readable code stored in a processor-readablerecording medium included in a network device. The processor-readablerecording medium includes all kinds of recording media storing datareadable by a processor. Examples of the processor-readable recordingmedium include a ROM, a RAM, a CD-ROM, a magnetic tape, a floppy disk,an optical data storage device and the like, and an implementation ascarrier waves such as transmission over the Internet. In addition, theprocessor-readable recording medium may be distributed to computersystems connected through a network, stored and executed as codereadable in a distributed manner.

Although the preferred embodiments of the present invention have beendisclosed for illustrative purposes, those skilled in the art willappreciate that various modifications, additions and substitutions arepossible, without departing from the scope and spirit of the inventionas disclosed in the accompanying claims. Such modifications should notbe individually understood from the technical spirit or prospect of thepresent invention.

Those skilled in the art will appreciate that the present invention maybe changed and modified in various ways without departing from thespirit and essential characteristics of the present invention.Therefore, the present invention is intended to include change andmodification of the present invention provided in the accompanyingclaims and the equivalency range.

In the specification, both the apparatus invention and the methodinvention are mentioned, and description of both the apparatus inventionand the method invention can be applied complementarily.

Mode for Invention

Various embodiments have been described in the Best Mode for theInvention.

INDUSTRIAL APPLICABILITY

The present invention is used in a series of broadcast signaltransmission/reception fields.

Those skilled in the art will appreciate that the present invention maybe changed and modified in various ways without departing from thespirit and essential characteristics of the present invention.Therefore, the present invention is intended to include change andmodification of the present invention provided in the accompanyingclaims and the equivalency range.

1. A method for transmitting a signal in a digital transmitter, themethod comprising: generating at least one link layer packet based oninput data, wherein the input data relates to an Internet Protocol (IP)packet or a Moving Picture Experts Group (MPEG)-2 Transport Stream (TS),wherein the at least one link layer packet includes a payload, at leastone of a base header, an additional header or an optional header havingSub-stream Identifier (SID) for indicating a sub-stream identifier forthe at least one link layer packet; and transmitting the signal carryingthe at least one link layer packet based on a Physical Layer Pipe (PLP),wherein the generating includes: compressing a header of the IP packet,and performing an adaptation function for the IP packet based on threeadaptation modes, wherein the three adaptation modes includes: a firstadaptation mode in which a first Initialization and Refresh (IR) packet,a first IR Dynamic (IR-DYN) packet and a first compressed packet arebypassed by an adaption module, a second adaptation mode in whichcontext information of a second IR packet is extracted, and the secondIR packet is converted into a second IR-DYN packet, and a thirdadaptation mode in which context information of a third IR packet isextracted, context information of a third IR-DYN packet is extracted,the third IR packet is converted into a second compressed packet, andthe third IR-DYN packet is converted into a third compressed packet. 2.The method for transmitting a broadcast signal of claim 1, wherein linklayer signaling information includes mapping information for the PLP andthe IP packet carried in the PLP, wherein the mapping informationincludes PLP number information, IP/User Datagram Protocol (UDP)sub-stream number information included in the PLP, source IP addressinformation for each IP/UDP sub-stream, destination IP addressinformation, source UDP port information and destination UDP portinformation, and wherein the SID is used for filtering the IP/UDPsub-stream included in the PLP in a link layer level.
 3. The method ofclaim 2, wherein additional header of the link layer packet includesflag information indicating whether the SID is included in the optionalheader.
 4. The method of claim 3, wherein the link layer signalinginformation includes description information for IP header compression,and wherein the description information includes the extracted contextinformation.
 5. The method of claim 4, wherein a link layer signalingpacket is included in the PLP forwarding a service list table, and theservice list table is signaling information describing a service.
 6. Adigital transmitter for transmitting a signal, the digital transmittercomprising: a processor configured to generate at least one link layerpacket based on input data, wherein the input data relates to anInternet Protocol (IP) packet or a Moving Picture Experts Group (MPEG)-2Transport Stream (TS), wherein the at least one link layer packetincludes a payload, at least one of a base header, an additional headeror an optional header having Sub-stream Identifier (SID) for indicatinga sub-stream identifier for the at least one link layer packet; and atransmitting module configured to transmit the signal carrying the atleast one link layer packet based on a Physical Layer Pipe (PLP),wherein the processor is configured to: compress a header of the IPpacket, and perform an adaptation function for the IP packet based onthree adaptation modes, wherein the three adaptation modes includes: afirst adaptation mode in which a first Initialization and Refresh (IR)packet, a first IR Dynamic (IR-DYN) packet and a first compressed packetare bypassed by an adaption module, a second adaptation mode in whichcontext information of a second IR packet is extracted, and the secondIR packet is converted into a second IR-DYN packet, and a thirdadaptation mode in which context information of a third IR packet isextracted, context information of a third IR-DYN packet is extracted,the third IR packet is converted into a second compressed packet, andthe third IR-DYN packet is converted into a third compressed packet. 7.The digital transmitter of claim 6, wherein the link layer signalinginformation includes mapping information for the PLP and the IP packetcarried in the PLP, wherein the mapping information includes PLP numberinformation, IP/User Datagram Protocol (UDP) sub-stream numberinformation included in the PLP, source IP address information for eachIP/UDP sub-stream, destination IP address information, source UDP portinformation and destination UDP port information, and wherein the SID isused for filtering the IP/UDP sub-stream included in the PLP in a linklayer level.
 8. The digital transmitter of claim 7, wherein additionalheader of the link layer packet includes flag information indicatingwhether the SID is included in the optional header.
 9. The digitaltransmitter of claim 8, wherein the link layer signaling informationincludes description information for IP header compression, and whereinthe description information includes the extracted context information.10. The digital transmitter of claim 9, wherein the link layer signalingpacket is included in the PLP forwarding a service list table, and theservice list table is signaling information describing a service.
 11. Amethod for receiving a signal in a digital receiver, the methodcomprising: receiving the signal carrying at least one link layer packetbased on a Physical Layer Pipe (PLP); processing the at least one linklayer packet, wherein the at least one link layer packet relates to anInternet Protocol (IP) packet or a Moving Picture Experts Group (MPEG)-2Transport Stream (TS), wherein the at least one link layer packetincludes a payload, at least one of a base header, an additional headeror an optional header having Sub-stream Identifier (SID) for indicatinga sub-stream identifier for the at least one link layer packet; andwherein the processing includes: starting a first decompression from adetected Initialization and Refresh (IR) packet in a first adaptationmode, starting a second decompression from a detected IR Dynamic(IR-DYN) packet in a second adaptation mode, and starting a thirddecompression with any compressed packet in a third adaption mode. 12.The method of claim 11, wherein link layer signaling informationincludes mapping information for the PLP and the IP packet carried inthe PLP, wherein the mapping information includes PLP numberinformation, IP/User Datagram Protocol (UDP) sub-stream numberinformation included in the PLP, source IP address information for eachIP/UDP sub-stream, destination IP address information, source UDP portinformation and destination UDP port information, and wherein the SID isused for filtering the IP/UDP sub-stream included in the PLP in a linklayer level.
 13. The method of claim 12, wherein additional header ofthe link layer packet includes flag information indicating whether theSID is included in the optional header.
 14. The method of claim 13,wherein the link layer signaling information includes descriptioninformation for IP header compression, and wherein the descriptioninformation includes the extracted context information.
 15. The methodof claim 14, wherein a link layer signaling packet is included in thePLP forwarding a service list table, and the service list table issignaling information describing a service.
 16. A digital receiver forreceiving a signal, the digital transmitter comprising: a receivingmodule configured to receive the signal carrying at least one link layerpacket based on a Physical Layer Pipe (PLP); a processor configured toprocess the at least one link layer packet, wherein the at least onelink layer packet relates to an Internet Protocol (IP) packet or aMoving Picture Experts Group (MPEG)-2 Transport Stream (TS), wherein theat least one link layer packet includes a payload, at least one of abase header, an additional header or an optional header havingSub-stream Identifier (SID) for indicating a sub-stream identifier forthe at least one link layer packet; and wherein the processor isconfigured to: start a first decompression from a detectedInitialization and Refresh (IR) packet in a first adaptation mode, starta second decompression from a detected IR Dynamic (IR-DYN) packet in asecond adaptation mode, and start a third decompression with anycompressed packet in a third adaption mode.
 17. The digital receiver ofclaim 16, wherein link layer signaling information includes mappinginformation for the PLP and the IP packet carried in the PLP, whereinthe mapping information includes PLP number information, IP/UserDatagram Protocol (UDP) sub-stream number information included in thePLP, source IP address information for each IP/UDP sub-stream,destination IP address information, source UDP port information anddestination UDP port information, and wherein the SID is used forfiltering the IP/UDP sub-stream included in the PLP in a link layerlevel.
 18. The digital receiver of claim 17, wherein additional headerof the link layer packet includes flag information indicating whetherthe SID is included in the optional header.
 19. The digital receiver ofclaim 18, wherein the link layer signaling information includesdescription information for IP header compression, and wherein thedescription information includes the extracted context information. 20.The digital receiver of claim 19, wherein a link layer signaling packetis included in the PLP forwarding a service list table, and the servicelist table is signaling information describing a service.